Language Shootout

Thomas Wouters thomas at xs4all.net
Tue Jul 10 03:16:42 EDT 2001


On Tue, Jul 10, 2001 at 11:53:35AM +0800, Malcolm Tredinnick wrote:
> On Tue, Jul 10, 2001 at 02:26:44AM +0000, Paul Winkler wrote:
> > Fredrik Lundh wrote:
> > > does your fastest iterative solution beat this one?

[ Fredrik does 'def fib(..); def fib(.., fib=fib, ...); ]

> > That's pretty fast, once I got it to work... but still not as fast as
> > my best one. Yours iis definitely interesting, largely because I
> > don't understand what the hell it does. If I rename one of the fibs
> > and change the appropriate call to use the new name, it still computes
> > fibonacci numbers but performance goes way down as N rises. So you're
> > somehow relying on the duplicated names for speed. That's a pretty
> > weird optimization technique.

Note that there is no reason for the performance to drop dramatically as
long as you change the correct names: you need to change the first
function's name, both 'fib's in the argument list of the second function (so
both 'fib' and 'fib' in 'fib=fib') and all occurances of 'fib' in the second
function's body.

> Ooh, ooh ... I know this one. :-)

> /F's solution makes sure that the code objcet of the first 'fib' is in
> the local namespace of the second 'fib' function. This speeds up lookups
> to it significantly (local variables are implemented as a dictionary,
> globals are not).

No, that's reversed :) Globals *are* a dictionary, locals are not. If a name
is known to be local (by the compiler), and the local namespace can't be
modified indirectly (by 'from .. import *' or a bare 'exec',) the variable
access is compiled into a simple array index, which is much faster than a
dictionary lookup. If you put a bare, useless 'exec' in the function, you'll
likely see a dramatic performance drop :)

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!




More information about the Python-list mailing list