01.06.17 12:20, Victor Stinner пише:
2017-06-01 10:40 GMT+02:00 Antoine Pitrou <solip...@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
_______________________________________________
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
