Tim Peters wrote: > [Skip Montanaro] > > [on assorted freelists] > >>These shortcomings could be remedied by suitable inspection >>functions added to sys for debug builds. > > If someone cares enough <wink>, sure. > >>This leads me to wonder, has anyone measured the cost of deleting the >>int and float free lists when pymalloc is enabled? I wonder how >>unbearable it would be. > > Vladimir did when he was first developing pymalloc, and left the free lists > in deliberately. I haven't tried it. pymalloc is a bit faster since then, > but will always have the additional overhead of needing to figure out > *which* freelist to look in (pymalloc's free lists are segregated by block > size), and, because it recycles empty pools among different block sizes too, > the overhead on free of checking for pool emptiness. The int free list is > faster in part because it's so damn Narcissistic <0.7 wink>. If someone really care, I suppose that the garbage collector could do an occasional scan of the int free list and chop of the tail after a certain number of entries. FWIW, Unicode free lists have a cap to limit the number of entries in the list to 1024. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, May 06 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2003, Charleroi, Belgium: 49 days left
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