Why is Python so slow ?- revisited.

[Michael Hudson]

bparsia at email.unc.edu (Bijan Parsia) writes:

> William Dandreta <wjdandreta at worldnet.att.net> wrote:
[snip]
> > In addition, there are 3 function calls in each replace. Logic
> > says eliminating one improve speed by 1/3.
> 
> Er.. no logic I know of :) Remember that "obvious" reasoning typically
> leads you astray when thinking about optimization. 

Hear hear.

> The key, as I have written, is the *lookup* of the method/function.

Are you really sure about this?  I was under the impression that it
was the cruft at the top of eval_code2 in ceval.c that was the major
overhead of a function call.  It certainly is in some circumstances,
though I guess it may be possible that in others method lookup
dominates.  Do you have numbers?

> These are *not* resolved at compile time, but at run time. They are
> *not* cached (unless you do so manually), they are performed from
> scratch each time.
> 
> > But on second thought, the one I eliminated was a call to a python.py
> > library module, the other 2 function calls are to functions in strop, a
> > compiled C 'module'. I'll have to test it to be sure.
> 
> Try saving the function to a local var and using it. I'd be interested
> to see what happens.

Does Python 1.2 have the local variable optimisation?  It would still
probably help though.

Cheers,
M.

-- 
    -Dr. Olin Shivers,
     Ph.D., Cranberry-Melon School of Cucumber Science
                                           -- seen in comp.lang.scheme