Introduce StringBuilder utility around raw_string_ostream

[Chandler Carruth]

On Thu, Jun 12, 2014 at 4:16 PM, Alp Toker <alp at nuanti.com> wrote:

> Okay, but that's still causing std::string heap allocations.
>

Ok, all of the discussion thus far has focused exclusively on preventing
bugs, so that was where I focused my suggestion.


>
> With my approach I can do:
>
>   typedef SmallStringBuilder<128> StringBuilder;
>

You can also achieve the same results with my suggestion... Nothing I
suggested is *really* tied to the std::string-composing variant of the
raw_*_ostream helpers...


>
> That turns a whole lot of allocations and strlens across the board into
> no-ops with a simple centralised change (patch attached, based on Yaron
> Keren's suggestion). This really *does* make an impact and there are
> secondary benefits to consider like reduced fragmentation (though I don't
> have figures, it's clearly going to help). Stack allocation always wins for
> small strings outside of recursion scenarios.
>

You don't have to teach me this. ;] I've spent a decent time turning heap
allocations into stack allocations throughout Clang and LLVM.


> And the patch also enforces clean storage reset() which is a really tricky
> operation to do manually with an ostream (requires sequential flush,
> storage reset, and sync -- do we really expect people to hand-write that
> without bugs?)
>

This is certainly a handy operation. Why not add it to the existing stream
classes? It seems useful regardless of whether you want internal or
external storage.


>
> And it'll be visible to further PGO optimisations (anything that tunes a
> SmallString will apply here too).
>

I don't know what this means... I don't think that my suggestion is in any
way different from the perspective of PGO....


>
> On the other hand the approach you suggested just adds some syntactic
> sugar, at the cost of tying the code closer to std::string heap storage --
> exactly what I'm incrementally working to avoid.
>

Again, I'm moderately sure you can achieve all the non-std::string storage
you want with my suggestion. What I'm suggesting is a general technique for
embedding storage inside of a stream object in a way that can easily be
used with the existing APIs. It should be generalizable to whatever stream
objects are useful to embed storage within....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140612/9bd638e0/attachment.html>