Less good ;-) results from Rittle's string allocator

[Paolo Carlini <pcarlini at unitus dot it>]

Hi all,

as I already mentioned before, lately I have run more benchmarks comparing the current
with the new allocator. The following is one of the nastiest variant of Stefan's testcase
which I could think of in terms of the improvement bring about by the new allocator. Note
however, that in this case too, there is *no* regression wrt the current situation. For
comparison, I have also reported gcc-2.95.3 timings.

In the next few days I'd like to test a little bit the effect of Phil Edwards proposal to
increase _MAX_BYTES to 256 in stl_alloc.h (the new one would be modified s/256/512/).

As regards this last point, what do you all believe of including stl_alloc.h in
basic_string.tcc?

I think that in the light of the new development plans involving stl_alloc.h it is not a
good idea to keep a 128(256) hardwired in the new allocator.

Cheers,
Paolo.

(PII-400, 256M, linux2.4.16, glibc2.2.4, -O2)

/////////////
#include <string>

int main()
{
        std::string s;

        for(int i=0; i<N; i++)
          {
            s = "a";
            for(int j=0; j<M; j++)
              {
                s = s + s;
              }
          }
}
/////////////

------
N = 10
M = 25
------
gcc version 3.1 20011122 (experimental)
---------------------------------------
4.320u 4.980s 0:09.47 98.2%     0+0k 0+0io 166pf+0w
4.190u 5.110s 0:09.49 97.9%     0+0k 0+0io 166pf+0w
4.000u 5.280s 0:09.48 97.8%     0+0k 0+0io 166pf+0w
4.220u 5.090s 0:09.47 98.3%     0+0k 0+0io 166pf+0w
3.940u 5.370s 0:09.47 98.3%     0+0k 0+0io 166pf+0w

gcc version 3.1 20011122 (experimental) + Loren's patch
(__malloc_header_size == 16)
-------------------------------------------------------
4.020u 5.350s 0:09.55 98.1%     0+0k 0+0io 165pf+0w
4.540u 4.810s 0:09.55 97.9%     0+0k 0+0io 165pf+0w
4.220u 5.140s 0:09.56 97.9%     0+0k 0+0io 165pf+0w
4.020u 5.340s 0:09.55 98.0%     0+0k 0+0io 165pf+0w
4.280u 5.180s 0:09.65 98.0%     0+0k 0+0io 165pf+0w

gcc version 2.95.3 (+ glibc patches)
------------------------------------
2.960u 3.250s 0:06.32 98.2%     0+0k 0+0io 95pf+0w
2.720u 3.460s 0:06.31 97.9%     0+0k 0+0io 95pf+0w
2.840u 3.340s 0:06.31 97.9%     0+0k 0+0io 95pf+0w
2.890u 3.300s 0:06.31 98.0%     0+0k 0+0io 95pf+0w
3.040u 3.150s 0:06.31 98.0%     0+0k 0+0io 95pf+0w


-------
N = 20
M = 400
-------
gcc version 3.1 20011122 (experimental)
---------------------------------------
4.710u 6.040s 0:10.96 98.0%     0+0k 0+0io 166pf+0w
4.930u 5.820s 0:10.97 97.9%     0+0k 0+0io 166pf+0w
4.660u 6.090s 0:10.95 98.1%     0+0k 0+0io 166pf+0w
4.670u 6.060s 0:10.95 97.9%     0+0k 0+0io 166pf+0w
4.700u 6.110s 0:11.01 98.1%     0+0k 0+0io 166pf+0w

gcc version 3.1 20011122 (experimental) + Loren's patch
(__malloc_header_size == 16)
-------------------------------------------------------
4.970u 5.880s 0:11.06 98.1%     0+0k 0+0io 165pf+0w
4.760u 6.100s 0:11.06 98.1%     0+0k 0+0io 165pf+0w
4.460u 6.400s 0:11.07 98.1%     0+0k 0+0io 165pf+0w
4.680u 6.180s 0:11.06 98.1%     0+0k 0+0io 165pf+0w
4.620u 6.260s 0:11.10 98.0%     0+0k 0+0io 165pf+0w

gcc version 2.95.3 (+ glibc patches)
------------------------------------
2.870u 4.180s 0:07.17 98.3%     0+0k 0+0io 95pf+0w
2.980u 4.050s 0:07.15 98.3%     0+0k 0+0io 95pf+0w
2.800u 4.210s 0:07.16 97.9%     0+0k 0+0io 95pf+0w
3.140u 3.890s 0:07.16 98.1%     0+0k 0+0io 95pf+0w
3.090u 3.930s 0:07.17 97.9%     0+0k 0+0io 95pf+0w