[Python-Dev] Re: [ python-Patches-876206 ] scary frame speed hacks (original) (raw)

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