Jack Diederich wrote:
PyObject_MALLOC does a good job of reusing small allocations but it
can't quite manage the same speed as a free list, especially for things that
have some extra setup involved (tuples have a free list for each length).
I would question that statement, for any practical
[Jack Diederich]
PyObject_MALLOC does a good job of reusing small allocations but it
can't quite manage the same speed as a free list, especially for things that
have some extra setup involved (tuples have a free list for each length).
[Martin v. Löwis]
I would question that statement, for
Tim Peters wrote:
With current trunk that printed
[2.9363677646013846, 2.9489729031005703, 2.9689538729183949]
After changing
#define MAXSAVEDTUPLES 2000
to
#define MAXSAVEDTUPLES 0
the times zoomed to
[4.5894824930441587, 4.6023111649343242, 4.629560027293957]
That's
On Tue, Jun 27, 2006 at 02:09:19PM -0400, Alexander Belopolsky wrote:
Setobject code allocates several internal objects on the heap that are
cleaned up by the PySet_Fini function. This is a fine design choice,
but it often makes debugging applications with embedded python more
difficult.
I
That was a purely altruistic proposal. I've already
discovered that sets are finalized and that some code that
works with dict emulating a set may not work with a set. It
will not make much difference for me if my proposal will be
implemented in 2.6 or even in 3.0, but the sooner
Kristján V. Jónsson kristjan at ccpgames.com writes:
Can this not be resolved by carefully adjusting the order of finalization?
Absolutely. This is exactly what I did in my interned patch and this
is what prompted my proposal.
If code can be bootstrapped it can be strootbapped.
Agree.
Kristján V. Jónsson wrote:
As a side note, is there a finalization order list for imported modules?
If they are Python modules, more or less, yes. Extension modules
cannot currently be finalized (I plan to change that for Py3k).
See PyImport_Cleanup for the precise algorithm used; there are
Fredrik Lundh fredrik at pythonware.com writes:
given that CPython has about a dozen Fini functions, what exactly is it
that makes PySet_Fini so problematic ?
I have not been bitten by the other _Fini yet. ;-)
I was bitten by PySet_Fini when I tried to replace the interned dict with a
Alexander Belopolsky wrote:
I feel that set is a more basic object than dict
I don't feel that way; dict is more basic, set is just a special case of
dict for performance reasons. Also, dict is used to define and implement
the language itself, set is just a predefined type.
but dictobject
On 6/29/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
... dict is more basic, set is just a special case of
dict for performance reasons. Also, dict is used to define and implement
the language itself, set is just a predefined type.
I guess it can be seen either way, just as a chicken and an
Alexander Belopolsky [EMAIL PROTECTED] wrote:
On 6/29/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
... dict is more basic, set is just a special case of
dict for performance reasons. Also, dict is used to define and implement
the language itself, set is just a predefined type.
I guess it
On 6/29/06, Josiah Carlson [EMAIL PROTECTED] wrote:
I disagree. You can get everything you need with a dict, and making
sets a part of the language (besides being a builtin type), would
necessarily add more overhead and maintenance to the language for little
gain. If you need set-like
Setobject code allocates several internal objects on the heap that are
cleaned up by the PySet_Fini function. This is a fine design choice,
but it often makes debugging applications with embedded python more
difficult.
I propose to eliminate the need for PySet_Fini as follows:
1. Make dummy and
Alexander Belopolsky wrote:
Setobject code allocates several internal objects on the heap that are
cleaned up by the PySet_Fini function. This is a fine design choice,
but it often makes debugging applications with embedded python more
difficult.
given that CPython has about a dozen Fini
14 matches
Mail list logo
