ANN: Stackless Python 0.2

[Christian Tismer]

Tim Peters wrote:
> 
> [Tim sez Python stores space for each code object's "Python stack" in a
>  runtime frame object]
> 
> [Toby J Sargeant wondering about frame allocs]
...
> > It seems that this should affect Stackless Python equally as
> > much.
> 
> No more so than Stackful Python:  Python has always worked this way;
> Stackless Python doesn't change this aspect.

And this was one of the temptations to start this at all.
We pay already some amount of runtime for the frame thing.
Then, we should make full use of it. Doing not so would
be a waste and not optimum.

> 
> > 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...
> 
> The code is in Objects/frameobject.c, and easy to follow.  frameobjects are
> recycled  via their own free list.  Typically the total number of
> frame-associated mallocs is proportional to the maximum depth of the call
> stack, not to the number of calls made.
> 
> Setting up a Python frame remains expensive, but for other reasons.

The last word on this isn't spoken yet, since I didn't try
to optimize frames. But I will see what to do (later).

There are two things, which at the moment are still too
intermingled. I will try to break things apart more in the
next stackless verison. Currently, a frame is constructed
from a code object, by examining the code object's properties.
This is done in frameobject.c. The engine then modifies
the local registers in the frame object, according to
parameters of the given function call.

This is by far not optimum. If a function is called repeatedly
in the same context, the frame could stay initialized and be
reused. I believe there are very many contexts where just
one or two arguments of a function call change, and the
frame would only need to update these two fast locals!

Maybe caching this a little, by code object and caller
location would pay off. Will think more about it.

tim-this-is-continuation-prediction - ly y'rs  - chris

-- 
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