[Python-Dev] Windows Low Fragementation Heap yields speedup of ~15%

[Evan Jones]

On Thu, 2005-02-17 at 22:38, Tim Peters wrote:
> Then you allocate a small object, marked 's':
>
> bbbbbbbbbbbbbbbsfffffffffffffffffffffffffffffff

Isn't the whole point of obmalloc is that we don't want to allocate "s" 
on the heap, since it is small? I guess "s" could be an object that 
might potentially grow.

> One thing to take from that is that LFH can't be helping list-growing
> in a direct way either, if LFH (as seems likely) also needs to copy
> objects that grow in order to keep its internal memory segregated by
> size.  The indirect benefit is still available, though:  LFH may be
> helping simply by keeping smaller objects out of the general heap's
> hair.

So then wouldn't this mean that there would have to be some sort of 
small object being allocated via the system malloc that is causing the 
poor behaviour? As you mention, I wouldn't think it would be list 
objects, since resizing lists using LFH should be *worse*. That would 
actually be something that is worth verifying, however. It could be 
that the Windows LFH is extra clever?

> I'm afraid the only you can know for sure is by obtaining detailed
> memory maps and analyzing them.

Well, it would also be useful to find out what code is calling the 
system malloc. This would make it easy to examine the code and see if 
it should be calling obmalloc or the system malloc. Any good ideas for 
easily obtaining this information? I imagine that some profilers must 
be able to produce a complete call graph?

Evan Jones