Introduce StringBuilder utility around raw_string_ostream

Alp Toker alp at nuanti.com
Mon Jun 30 16:17:37 PDT 2014


On 01/07/2014 01:12, Chandler Carruth wrote:
> Just as a very small correction to some of the facts here:
>
> On Mon, Jun 30, 2014 at 2:24 PM, Alp Toker <alp at nuanti.com 
> <mailto:alp at nuanti.com>> wrote:
>
>     1) Uses a non-heap container (SmallString) by default.
>
>
> std::string has a small-string optimization in both libc++ and, 
> whenever GCC takes the ABI break and conforms with C++11, libstdc++

That's an optimization for strings less than 10-22 characters, and is 
libc++-specific. Worst of all it's non-customizable and pessimal, say, 
if we *know* the string is likely to be, say, 40 bytes at a certain 
point-of-use.

Examining the hundreds of SmallStrings in the LLVM code base, only a 
handful out of those would benefit in any way from libc++'s small string 
feature with the remainder thrashing the heap. The proposed patch does a 
great job with all of them.

>
> So you don't have to use SmallString to avoid heap allocations. The 
> primary advantage of SmallString is the ability to customize how many 
> bytes are available in the internal buffer.

Yes, the proposed patch frequently overrides the suggested 128 byte 
stack buffer size in cases where we have a better idea how large our 
string will be.

I'm familiar with libc++ and other standard C++ libraries, and basically 
don't see any overlap with the string facilities provided there. As 
Yaron pointed out, this is much more a natural continuation of ADT's 
data types.

Alp.


-- 
http://www.nuanti.com
the browser experts




More information about the llvm-commits mailing list