A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2017-June/148122.html below:

[Python-Dev] "Global freepool"

[Python-Dev] "Global freepool" [Python-Dev] "Global freepool"Victor Stinner victor.stinner at gmail.com
Thu Jun 1 05:20:05 EDT 2017
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 :-)

By the way, the Linux kernel uses a "SLAB" allocator for the most
common object types like inode. I'm curious to know if CPython would
benefit of a similar allocator for our most common object types? For
example types which already use a free list.

https://en.wikipedia.org/wiki/Slab_allocation

Victor
More information about the Python-Dev mailing list

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