Tim Peters wrote:
> [Christian Tismer]
>
>>It might be not so hard to make trashcan able
>>to register new types at run-time.
>
>
> They don't have to do anything extra now -- registering with gc is
> sufficient in current CVS.
Do you remember who wrote Trashcan? :-)
Oh, I see, you want to point out that I would
cause other changes to be done. I wasn't aware
that trashcan is used in other places but those
I implemented, yet.
> It's also a fine fit: if they're fat containers
> for which the trashcan is appropriate, they can also be involved in cycles.
Indeed it is a fine fit. After some thought, I begin
to believe that they fit so well, that they could
become *one* option (and trashcan is unchanged):
- Either you want GC, then you also get trashcan.
- Or you dont want it. Trashcan disappears, too.
My reasoning is simple: If people think they can
resolve their cycles by hand, then they most
probably also can take care of not creating deeply
nested structures to be killed.
And if I hadn't written trashcan, I doubt it would
exist today, at all. :-)
As a side remark, since you asked me about the
relevance of Stackless: I just realized that with
Stackless 2.0, the need for trashcan is completely
gone, and I will disable the trashcan macros for
a stackless build of Python in my trunk.
Thanks for helping me to think clearly.
> Note too that people can get back more memory than gc consumes by declaring
> new-style classes to use __slots__. That's a new memory-optimization
> gimmick, and an effective one.
Very true. The flipside is, that in memory-critical
applications people tend to avoid myriads of tiny
container objects and already use tuples, instead.
But these are now more expensive, and they're biten.
I think one way to overcome this problem is to allow
new-style classes to specify whether they want to be
GC-ed or not. We (I) could implement a new __use_gc__
flag or something to give users an option.
Alternatively, to GC or not GC could be driven by
inheritance. I used that in my flextype implementation.
When a class inherits from no GC-ed anchestors only,
it doesn't install GC as well.
Anyway, with something like that it should be possible
to build tiny container objects of fixed size (again
saving a word) which are even smaller than un-GC-ed
tuples.
As a last remark (although this is too long already),
I'd also like to extend the __slots__ syntax by the
ability to express "embedded types", like the types
supported by array. This again saves a lot of memory
when you know your attribute is always some simple type,
which need not become an object.
cheers - chris
--
Christian Tismer :^) <mailto:tismer@tismer.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
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