[Python-Dev] Re: [ python-Patches-876206 ] scary frame speed hacks

Terry Reedy tjreedy at udel.edu
Tue Mar 2 14:37:45 EST 2004


"Armin Rigo" <arigo at tunes.org> wrote in message
news:20040301161215.GA3963 at vicky.ecs.soton.ac.uk...
> Hello,
>
> Takes 3.26s instead of just 2.64s.  This is a major speed hit (20%).

Yes.  People will notice.  I feel safe in predicting that an avoidable 20%
slowdown will generate 'strong' objections, especially from devotees of the
functional/recursive style.

> On the other hand, recursive functions are not so common in Python,

I think the frequency varies considerably depending on the problem domain
and the inductional persuasion of the programmer: iterationist vs.
recursionist vs. inbetweenist.

While Python, with its 'for' statements, encourages the iterative form of
linear induction, branching recursion is usually much clearer that the
iterative equivalent, and Python is meant to encourage readable code.
Since branching recursion usually generates a wide but shallow (virtual)
tree of argument structures, the depth limit is usually not a problem for
such cases.

> (2) Don't remove the frame freelist but combine it with the new patch.
> This would give the best of both worlds performance-wise, but the frame
> allocation code becomes convoluted.

I have sometimes thought that maybe there should be a means of 'declaring',
or perhaps 'detecting' a function to be recursive, with two ramifications:

1. Recursive functions would be faster if the definition name of the
function, when used for recursive calls within the function, could be coded
as a local rather than global, and perhaps even a local constants, so that
the code was hard-coded to call itself.  (I am aware that the separation of
code and function might make this a bit tricky.)

2. Multiple execution frames per function are only needed for recursion
(which is why old Fortran, with only one per, forbade recursion, even
indirectly).  So non-recursive functions could be perhaps sped up -- as you
are proposing to do,

(Automated recursion to iteration transformation is a more pie-in-the-sky
third possibility.)

If function decorators are added, perhaps there could be a builtin
recursive() decorator that would manipulate the function and maybe the code
for faster running.
To justify asking people to run around revising their code, this should
preferably be faster than at present, and not just as fast.

Terry J. Reedy






More information about the Python-Dev mailing list