PATCH/RFC Pool allocations of QStringData objects..

[Maks Orlovich]

On Saturday 18 January 2003 03:40 am, Andrew Morton wrote:
> Maks Orlovich <mo002j@mail.rochester.edu> wrote:
> > +		//Don't pool too many.
> > +		if (count > 1000)
> > +		{
> > +			::free(alloc);
> > +			realFreed++;
> > +		}
> > +		else
>
> This is freeing the cache-hot memory while retaining the cache-cold memory.
> It would be better to implement full LIFO here.

Thanks for bringing up, I didn't think of that... However, looking at the 
usage patterns, I am not so sure that it'll be a net win (it's trading off 
beter cache behavior in some cases for more complex code in others, after 
all); since most of the time the code path either doesn't get hit for a long 
time (i.e. when the code may be creating a few temporary string objects, and 
then maybe using one result, etc. -- that's pretty much all that happens 
during app startup), or get hit a lot (i.e. cleanup-type thing), and when it 
does, since a QString has 2 heap-allocated parts (the QStringData control 
object and the actual data); we've done about 1000+ heap frees in a row - if 
not more -- which probably pretty much trashes the L1 cache anyway. And 
unfortunately, I can't think of a way to measure the effect realistically, 
either, even with cachegrind -- just don't see a way to script something 
realistic and reproducible, unfortunately :-(

Thanks,
-Maksim