[LLVMdev] SmallString + raw_svector_ostream combination should be more efficient

[Mehdi Amini]

> On Apr 19, 2015, at 7:40 AM, Yaron Keren <yaron.keren at gmail.com> wrote:
> 
> A very common code pattern in LLVM is
> 
>  SmallString<128> S;
>  raw_svector_ostream OS(S);
>  OS<< ...
>  Use OS.str()
> 
> While raw_svector_ostream is smart to share the text buffer itself, it's inefficient keeping two sets of pointers to the same buffer:
> 
>  In SmallString: void *BeginX, *EndX, *CapacityX
>  In raw_ostream: char *OutBufStart, *OutBufEnd, *OutBufCur
> 
> Moreover, at runtime the two sets of pointers need to be coordinated between the SmallString and raw_svector_ostream using raw_svector_ostream::init, raw_svector_ostream::pwrite, raw_svector_ostream::resync and raw_svector_ostream::write_impl.
> All these functions have non-inlined implementations in raw_ostream.cpp. 
> 
> Finally, this may cause subtle bugs if S is modified without calling OS::resync(). This is too easy to do by mistake.

FWIW I’ve been bitten exactly by this last week while updating an out-of-tree compiler to adapt API changes around streams (raw_pwrite_stream). On the positive aspect, I had to learn about the internal of the various streams ;)

The API for raw_svector_ostream is not nice on this aspect, but what is really missing is that there is no assertion to catch it.
I feel it is a bit off from the principle “easy to use, hard to misuse”.


> In this frequent case usage the client does not really care about S being a SmallString with its many useful string helper function. It's just boilerplate code for raw_svector_ostream. But it does cost three extra pointers, some runtime performance and possible bugs.
> 
> To solve all three issues, would it make sense to have raw_ostream-derived container with a its own SmallString like templated-size built-in buffer?

Not sure about the exact solution, but “something” could certainly be done to be more “user-friendly”. 

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150420/a4dd865a/attachment.html>