PATCH/RFC Pool allocations of QStringData objects..

[Maks Orlovich]

> This number of course, deserves a pause. This means, if it's correct, that
> we have created 100,000 QStringData and hence QString objects during the
> startup! And subtracting frees from allocs, we have some 26,784 strings in
> memory!

<snip>.

It's also a lot less scary if one sets up a proper limit on the history, like 
the one with defaults, and doesn't let their history file baloon to 1MB:

Had to do 5923/47406 allocs, 0/41550 frees

Which works out to 5856 live  strings, which is a whole lot better. 


New timings, with the more realistic scenario:

Base profile overhead:

KCounterProf::Cumulative: alloc = 4.42
KCounterProf::Cumulative: free = 3.58


KCounterProf::Cumulative: alloc = 4.30
KCounterProf::Cumulative: free = 3.55

KCounterProf::Cumulative: alloc = 4.39
KCounterProf::Cumulative: free = 3.55

Total(min): 7.94

Traditional:

KCounterProf::Cumulative: alloc = 17.23
KCounterProf::Cumulative: free = 13.95

KCounterProf::Cumulative: alloc = 17.32
KCounterProf::Cumulative: free = 13.82

KCounterProf::Cumulative: alloc = 17.18
KCounterProf::Cumulative: free = 13.95

Total(min): 31.13 
Real (w/o profile overhead): 23.19

This isn't much different from the previous results, despite quite a bit fewer 
allocations -- perhaps the pattern is worse? 

(The alternative is what we're getting scheduled, but the results below 
suggest it's unlikely - since minus 10ms, we would have to be in the same 
range as below, which one would then expect to have about the same 
probability of getting scheduled as well, no?)

Pooled:

KCounterProf::Cumulative: alloc = 7.27
KCounterProf::Cumulative: free = 3.54

KCounterProf::Cumulative: alloc = 7.36
KCounterProf::Cumulative: free = 3.54

KCounterProf::Cumulative: alloc = 7.34
KCounterProf::Cumulative: free = 3.53

Total(min): 10.81
Real (w/o profile overhead): 2.87.

Delta: 20.32.
Hmm. Better than last time. Something is weird here :-(