[Python-Dev] "Global freepool"

Larry Hastings larry at hastings.org
Thu Jun 1 14:44:11 EDT 2017



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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170601/547ab618/attachment.html>


More information about the Python-Dev mailing list