Why is Python so slow ?- revisited.

Michael Hudson mwh21 at cam.ac.uk
Tue Jun 20 10:12:47 EDT 2000


Thomas Wouters <thomas at xs4all.net> writes:

[snip] 
> def spam(x, y):
>     if x in range(1, y):
>         return 1
>     if x in range(y, 1):
>         return 1
>     return 0
> 
> Might not seem very useful, but it's just an example ;) This can
> easily be optimized, right ? We lookup 'range', it's a builtin, we
> store the address, and call it two times. Well, no. We dont *know*
> range a is a builtin, it could be a global that points elsewhere. If
> the 'spam' function contained a 'from module import *' or 'exec'
> statement, it could even be a local.
> 
> So, we have to check if range is still the same function. Which
> means we have to look it up and compare identity -- and we've
> already lost any advantage the cache could give us. Or we could
> place a marker on the __builtin__ module, and invalidate the cached
> entry of 'range' whenver 'range' is changed. But then we also have
> to add a marker to the global namespace, because something can *add*
> a range there.

One strategy occurs here is too assume that the global/builtin
namespace doesn't change all that often, so you compile `spam'
assuming that `range' refers to what it does at compile time, and then
if any function modifies builtins or the global namespace of `spam'
you throw away what you've compiled and start again (it's presumably
worthwhile to do this somewhat lazily, as the module namespace will
get repeatedly changed during mosule execution).

This strategy is used by MIT scheme (I think) and similar things are
done by most Common Lisps in their implementations of CLOS.

This would have the "advantage" of making functions which muck with
global namespaces howlingly expensive, which you might or might not
consider to be a good thing...

Hmm, implementation...

Cheers,
M.

-- 
  There are 'infinite' number of developed artifacts and one cannot
  develop appreciation  for them all.  It would be all right to not
  understand something, but it would be imbecilic to put judgements
  on things one don't understand.               -- Xah, comp.lang.lisp



More information about the Python-list mailing list