[Python-ideas] A Continuations Compromise in Python

Antoine Pitrou solipsis at pitrou.net
Sun May 3 17:16:10 CEST 2009


Steven D'Aprano <steve at ...> writes:
> 
> People spend time trying to speed up general purpose code in the 
> standard library, to save 1% or 2% on benchmarks.

Actually, it's quite rare that these patches (those which only yield a 1 or 2%
improvement) are accepted, except when they don't make the implementation more
complex.
Lots of other patches with more significant speedups on micro-benchmarks are
refused, too. You can find some of them in the bug tracker.

> and I for one haven't seen anyone 
> objecting to improving Python's general execution speed.

Not in the absolute, sure. If someone produces a patch speeding up recursive
calls it will be considered with the same criteria as any patch claiming to
improve performance (see above). This doesn't mean it will be accepted for sure.

> In this case, two recursive calls (one of which is a tail-call) takes 
> nearly 60% more time than a single recursive call in a while loop.

Why do you think recursion has anything to do with it, rather than simply the
fact that there are twice more function calls?

Besides, I object to the claim that solving the Towers of Hanoï problem is a
real-world example ;)

That said, it's true that recursive calls are probably costlier than
non-recursive ones, due to the fact that only one frame object is cached for
each code objects. But removing this limitation shouldn't make the common
(non-recursive) case slower, and it shouldn't increase memory consumption too
much, so it's not as easy as it seems.

Regards

Antoine.





More information about the Python-ideas mailing list