[Python-Dev] map() methods (was: Re: [Patches] Review (was: Please review before applying))

Vladimir Marangozov Vladimir.Marangozov@inrialpes.fr
Tue, 25 Apr 2000 08:13:32 +0200 (CEST)


Hi, I'm back on-line.

> [Tim]
> > Perhaps the 1.6 source distribution could contain a new "intriguing
> > experimental patches" directory?  Greg's list-comp and Christian's
> > Stackless have enough fans that this would probably be appreciated.
> > Perhaps some other things too, if we all run out of time (thinking
> > mostly of Vladimir's malloc cleanup and NeilS's gc).

I'd be in favor of including gc as an optional (experimental) feature.
I'm quite confident that it will evolve into a standard feature, in its
current or in an improved state. The overall strategy looks good, but
there are some black spots w.r.t its cost, both in speed and space.
Neil reported in private mail something like 5-10% mem increase, but
I doubt that the picture is so optimistic. My understanding is that
these numbers reflect the behavior of the Linux VMM in terms of effectively
used pages. In terms of absolute, peak requested virtual memory, things
are probably worse than that. We're still unclear on this...

For 1.6, the gc option would be a handy tool for detecting cyclic trash.
It will answer some expectations, and I believe we're ready to give some
good feedback on its functioning, its purpose, its limitations, etc.
By the time 1.6 is finalized, I expect that we'll know roughly its cost
in terms of mem overhead. Overall, it would be nice to have it in the
distrib as an experimental feature -- it would both bootstrap some useful
feedback, and would encourage enthousiasts to look more closely at DSA/GC
(DSA - dynamic storage allocation). By 1.7 (with Py3K on the horizon),
we would have a good understanding on what to do with gc and how to do it.

If I go one step further, what I expect is that the garbage collector
would be enabled together with a Python-specific memory allocator which
will compensate the cost introduced by the collector. There will some
some stable state again (in terms of speed and size) similar to what we
have now, but with a bonus pack of additional memory services.

> I definitely want Vladimir's patches in -- I feel very guilty for not
> having reviewed his latest proposal yet.  I expect that it's right on
> the mark, but I understand if Vladimir wants to wait with preparing
> yet another set of patches until I'm happy with the design...

Yes, I'd prefer to wait and get it right. There's some basis, but it
needs careful rethinking again. I'm willing to fit in the 1.6 timeline
but I understand very well that it's a matter of time :-).

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252