On 06/01/2017 02:20 AM, Victor Stinner wrote:
I would like to understand how private free lists are "so much"
faster. In fact, I don't recall if someone *measured* the performance
speedup of these free lists :-)
I have, recently, kind of by accident. When working on the Gilectomy I
turned off some freelists as they were adding "needless" complexity and
presumably weren't helping performance that much. Then I turned them
back on because it turned out they really did help.
My intuition is that the help in two major ways:
* Since they're a known size, you don't need to go through the
general-case code of looking up the right spot in usedpools (etc) to
get one / put one back in malloc/free.
* The code that recycles these objects assumes that objects from its
freelist are already mostly initialized, so it doesn't need to
initialize them.
The really crazy one is PyFrameObjects. The global freelist for these
stores up to 200 (I think) in a stack, implemented as a simple linked
list. When CPython wants a new frame object, it takes the top one off
the stack and uses it. Where it gets crazy is: PyFrameObjects are
dynamically sized, based on the number of arguments + local variables +
stack + freevars + cellvars. So the frame you pull off the free list
might not be big enough. If it isn't big enough, the code calls
*realloc* on it then uses it. This seems like such a weird approach to
me. But it's obviously a successful approach, and I've learned not to
argue with success.
p.s. Speaking of freelists, at one point Serhiy had a patch adding a
freelist for single- and I think two-digit ints. Right now the only int
creation optimization we have is the array of constant "small ints"; if
the int you're constructing isn't one of those, we use the normal slow
allocation path with PyObject_Alloc etc. IIRC this patch made things
faster. Serhiy, what happened to that patch? Was it actually a bad
idea, or did it just get forgotten?
//arry/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
