Home Original page

[Python-Dev] "Global freepool"

Serhiy Storchaka storchaka at gmail.com
Thu Jun 1 06:09:23 EDT 2017 
01.06.17 12:20, Victor Stinner пише:
> 2017-06-01 10:40 GMT+02:00 Antoine Pitrou <solipsis at pitrou.net>:
>> This is already exactly how PyObject_Malloc() works. (...)
> 
> Oh ok, good to know...
> 
>> IMHO the main thing the
>> private freelists have is that they're *private* precisely, so they can
>> avoid a couple of conditional branches.
> 
> 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 measured the performance boost of adding the free list for dict keys 
structures. [1] This proposition was withdraw in the favor of using 
PyObject_Malloc(). The latter solution is slightly slower, but simpler.

But even private free lists are not fast enough. That is why some 
functions (zip, dict.items iterator, property getter, etc) have private 
caches for tuples and the FASTCALL protocol added so much speedup.

At end we have multiple levels of free lists and caches, and every level 
adds good speedup (otherwise it wouldn't used).

I also have found many times is spent in dealloc functions for tuples 
called before placing an object back in a free list or memory pool. They 
use the trashcan mechanism for guarding from stack overflow, and it is 
costly in comparison with clearing 1-element tuple.

[1] https://bugs.python.org/issue16465
More information about the Python-Dev mailing list