Re: [Fwd: basic_string<> - useless because of its poor performance]

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

> _Rep::_S_create is a wrong place to do that. If one calls
> reserve(1024) he is expecting to prealloc 1024 bytes not
> 4096.

Um, no.  The sample implementation patch I posted would not touch a
reserve() call of 1024.  Anything less than a pagesize would be
handled in such a manner that it would never require more than double
the memory explicitly requested with reserve() or internally
determined e.g. by adding up sub-lengths of strings to append to one
another.

> Supposing a XML parsing program, where one has a lot of
> strings, it would be to memory expensiv to prealloc 4KB every time.

Fully agreed, we must be very careful while handling the cases
involving small strings.

> Moreover _Rep::_S_create is called in _S_construct. How much memory
> should be allocated in case, like

> string x("x");

> ?

In fact, it would be handled exactly as it is now.  It would allocate
one block of memory out of the high-speed internal-STL allocator.

> I think _M_mutate is the right place to do it.

I am really confused.  Adding the logic to round up the size of
allocations in _M_mutate wouldn't even fix the performance problem you
found with append().  What am I missing?

The only code path that is hit for every allocation is in _S_create().
It is the one place that both sets the __capacity and allocates the
actual memory.  I can think of no finer place to ensure all
allocations match our library policy of memory allocation sizes.

I am still digesting Nathan's last post on the matter.  I guess I need
to read the standard in this area before I attempt any performance
tuning here.

Regards,
Loren