ANN: Stackless Python 0.2

[Christian Tismer]

Gary Duzan wrote:
> 
> Toby J Sargeant wrote:
> >
...
>    This appears to be the conventional wisdom. The optimization class I
> took used an ML-like language, and the first thing we did was to move
> heap frames, which was the default, to the stack (i.e. closure
> optimization.)

Loosing much of flexibility by doing that, btw.

> It might be less of an issue in an interpreted language if it already has
> heap
> allocation (or other sorts of) overhead to deal with when making calls.
> There may be other allocation tricks which can be used, as well.
> 
> > It seems that this should affect Stackless Python equally as much. Does anyone
> > have anything to add on the subject? I would imagine that frames could be
> > allocated and managed in chunks to alleviate a lot of the memory management
> > load...
> 
>    I would think that as well (at least at first.) Maybe pools of different
> sizes of frame to limit the space overhead.

Maybe you should really look into the sources.
You are discussing things which are not Python
related, since this simply does not apply.

The Python "stacks" are so tiny that you can forget about them.
Allocations always never occour, unless your program runs
astray in recursion.

The cost of a call comes from the slightly complicated
function setup which is done all the time. Frames belong
to the fastest available Python objects already, 
like, say dictionaries.

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home