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/148132.html below:

[Python-Dev] "Global freepool"

[Python-Dev] "Global freepool" [Python-Dev] "Global freepool"INADA Naoki songofacandy at gmail.com
Thu Jun 1 06:08:15 EDT 2017
I thought pymalloc is SLAB allocator.
What is the difference between SLAB and pymalloc allocator?

On Thu, Jun 1, 2017 at 6:20 PM, Victor Stinner <victor.stinner at gmail.com> wrote:
> 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
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com
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