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

[Ryszard Kabatek <Ryszard dot Kabatek at softax dot pl>]

Loren James Rittle wrote:
> 
> In article <3B455CEA.E140F72@softax.pl>,
> Ryszard Kabatek <Ryszard.Kabatek@softax.pl> writes:
> 
> > The current implementation of basic_string is to slow to be useful.
> 
> Only if you fail to use reserve() wisely as suggested by Stroustrup... ;-)
> 
> I do basically agree that we should do something better than
> per-character growth given what we generally know about malloc
> implementations.  However, it is unclear that an exponential growth
> policy is wise.
> 
> > size_type
> > get_new_capacity(size_type n,
> >                  size_type max_len)
> [...]
> 
> > that will be called in _M_mutate and perhaps in other places (not in reserve).
> 
> I think _Rep::_S_create is the correct place to add the logic to
> adjust the request size sent to allocator<>::allocate() and to retain
> the adjusted __capacity.  I have made no attempt to add this logic in
> using (what looked like) a hook point or add the correct autoconf
> setup of the parameters (well, I have started to look at it).
> 

_Rep::_S_create is a wrong place to do that. If one calls reserve(1024) he is
expecting to prealloc 1024 bytes not 4096. Supposing a XML parsing program, where
one has a lot of strings, it would be to memory expensiv to prealloc 4KB every time.
Moreover _Rep::_S_create is called in _S_construct. How much memory should be allocated
in case, like

string x("x");

?

I think _M_mutate is the right place to do it.

Regards
-- 
Ryszard Kabatek