This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

Loren James Rittle wrote:
> In article <>,
> Ryszard Kabatek <> 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.

Ryszard Kabatek

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]