[Python-Dev] Windows Low Fragementation Heap yields speedup of
ejones at uwaterloo.ca
Fri Feb 18 22:58:36 CET 2005
On Thu, 2005-02-17 at 22:38, Tim Peters wrote:
> Then you allocate a small object, marked 's':
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
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?
More information about the Python-Dev