[LLVMdev] SmallString + raw_svector_ostream combination should be more efficient

Yaron Keren yaron.keren at gmail.com
Sun Apr 19 07:40:36 PDT 2015


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.

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150419/7bdc7a73/attachment.html>


More information about the llvm-dev mailing list