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

[Phillip J. Eby]

At 02:37 PM 3/2/04 -0500, Terry Reedy wrote:

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

It's not just recursive functions at issue.  It's also:

* a method that might call the same method on another instance (possibly 
indirectly via several other function or method calls)

* a generator function that might have more than one outstanding instance

* a function or method called from multiple threads

ALL of these scenarios involve multiple, simultaneously-active frames for a 
given code object, and most are non-obvious at the point of inspection.