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