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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4