Good numbers from Ritter's new string allocator

[Paolo Carlini]

> There is a bunch of stuff in std::string::_Rep to do with allocations. Is it
> supposed to handle this kind of tuning gracefully? If so, how? It seems
> obvious to me that the default allocation strategy is way off, and should
> be fixed.
>
> In particular:
> #if _GLIBCPP_ALLOC_CONTROL
>         // These function pointers allow you to modify the allocation
>         // policy used by the string classes.  By default they expand by
>         // powers of two, but this may be excessive for space-critical
>         // applications.
>
>         // Returns true if ALLOCATED is too much larger than LENGTH
>         static bool (*_S_excess_slop) (size_t __length, size_t __allocated);
>
>         inline static bool
>         __default_excess(size_t, size_t);
> #else
>         inline static bool
>         _S_excess_slop(size_t, size_t);
> #endif
>
> -benjamin

Yes.
In fact, at the time, it was briefly discussed the possibility to improve:

template<typename _CharT, typename _Traits, typename _Alloc>
  inline bool
#ifdef _GLIBCPP_ALLOC_CONTROL
    basic_string<_CharT, _Traits, _Alloc>::_Rep::
    _S_default_excess(size_t __s, size_t __r)
#else
    basic_string<_CharT, _Traits, _Alloc>::_Rep::
    _S_excess_slop(size_t __s, size_t __r)
#endif
    {
      return 2 * (__s <= 16 ? 16 : __s) < __r;
    }

but then Loren came with that patch (which indeed pragmatically is doing *very* well for
me) with the terse comment:

>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 ...

I will try to understand more of this in the next few hours....

Cheers,
Paolo.

P.S. Loren?