[Python-Dev] Looking for master thesis ideas involving Python

Phillip J. Eby pje at telecommunity.com
Wed Oct 29 13:25:52 EST 2003

At 06:01 PM 10/28/03 -0800, Brett C. wrote:
>Today I got the wheels turning on my masters thesis by getting an 
>adviser.  Now I just need a topic.  =)  The big goal is to do something 
>involving Python for a thesis to be finished by fall of next year (about 
>October) so as to have it done, hopefully published (getting into LL4 
>would be cool), and ready to be used for doctoral applications come 
>January 2005.
>So, anyone have any ideas?  The best one that I can think of is optional 
>type-checking.  I am fairly open to ideas, though, in almost any area 
>involving language design.

Throwing another Python-specific implementation issue into the ring...  how 
about performance of Python function calls?

Specifically, the current Python interpreter has a high overhead for 
argument passing and frame setup that dominates performance of simple 
functions.  One strategy I've been thinking about for a little while is 
replacing the per-frame variable size stacks (e.g. argument and block 
stacks) with per-thread stacks.  In principle, this would allow a few 
things to happen:

* Fixed-size "miniframe" workspace objects allocated on the C stack (with 
lazy creation of heap-allocated "real" frame objects when needed for an 
exception or a sys._getframe() call)

* Direct use of positional arguments on the stack as the "locals" of the 
next function called, without creating (and then unpacking) an argument 
tuple, in the case where there are no */** arguments provided by the caller.

This would be a pretty sizeable change to Python's internals (especially 
the core interpreter's handling of "call" operations), but could possibly 
produce double-digit percentage speedups for function calls in tight 
loops.  (I base this hypothesis on the speed difference between a function 
call and resuming a generator, and the general observation that the runtime 
of certain classes of Python programs is almost directly proportional to 
the number of function calls occurring.)

More information about the Python-Dev mailing list