classification
Title: free list management - list, dict, set
Type: behavior Stage:
Components: Interpreter Core Versions: Python 2.6
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: christian.heimes Nosy List: aimacintyre, christian.heimes, gregory.p.smith, rhettinger
Priority: normal Keywords: patch

Created on 2008-06-02 14:12 by aimacintyre, last changed 2008-06-07 15:21 by gregory.p.smith. This issue is now closed.

Files
File name Uploaded Description Edit
list_dict_set_clearfreelist.patch aimacintyre, 2008-06-02 14:12 patch adding free list clearing routines for list, dict & set objects
Messages (5)
msg67636 - (view) Author: Andrew I MacIntyre (aimacintyre) * Date: 2008-06-02 14:12
The attached patch adds free list clearing routines for the list, dict &
set objects.  These objects are the only ones with free lists that don't
already have some form of free list management API.  This patch
complements the patch in issue 2862.
msg67645 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2008-06-02 23:04
What is the point of expanding the C API for clearing individual 
types.  Isn't the single Fini function sufficient to clear them all?

Make the approaches consistent seems like a reasonable goal, but why 
did you choose the path where everything has its own clearing function 
instead of one to bind the all?  What apps need this?
msg67658 - (view) Author: Andrew I MacIntyre (aimacintyre) * Date: 2008-06-03 11:35
Freelist clearing functions for int and float were added by Christian,
and made available to Python code via a function in the sys module.  I
don't know who added the freelist clearing functions for the class,
frame, method, tuple and unicode objects, but they are called by
gc.collect().

Because the freelist implementations are all static to the relevant type
source files, functions within each object source file seem a reasonable
way of implementing the required functionality.

I don't see the need for them to be part of the public API, but I framed
this patch to fit in with what's already in place.

It is likely that the functionality of this patch is of minor value, and
can thus be rejected.

Indeed, I experimented with ripping out all freelists and making sure
that all types used PyMalloc, and the resulting interpreter is about
6-8% slower on a pybench run (FreeBSD 7.0, gcc 4.2.1, 6% slower on
32bit, 8% slower on 64bit, 64bit is ~15% faster than 32bit in either
case) than the trunk (r63501).  Individual micro-benchmarks in pybench
show 15-30% variations between the freelist & no freelist, but this
doesn't seem to significantly affect the running of the whole benchmark.

Issue 2862 is more important IMO, as the current situation has 2
different approaches to accessing freelist management, where I believe
there should only be 1.
msg67666 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2008-06-03 17:55
> I don't see the need for them to be part of the 
> public API, but I framed this patch to fit in 
> with what's already in place.

These should not be part of the public API; otherwise,
we lock-in the freelisting implementation detail and
cannot readily change it (since some C code may come
to rely on the new functions).
msg67808 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2008-06-07 15:21
everyone seems to be in agreement that this patch is a bad idea.  closing.
History
Date User Action Args
2008-06-07 15:21:45gregory.p.smithsetstatus: open -> closed
nosy: + gregory.p.smith
resolution: rejected
messages: + msg67808
keywords: patch, patch
2008-06-03 17:55:51rhettingersetpriority: high -> normal
keywords: patch, patch
messages: + msg67666
2008-06-03 11:35:45aimacintyresetkeywords: patch, patch
messages: + msg67658
2008-06-02 23:04:26rhettingersetkeywords: patch, patch
nosy: + rhettinger
messages: + msg67645
2008-06-02 14:12:57aimacintyrecreate