Python IS slow ! [was] Re: Python too slow for real world

Christian Tismer tismer at appliedbiometrics.com
Sun May 2 10:09:20 EDT 1999



Michael Hudson wrote:

[bytecode fiddling]

> > I'm really impressed. No, what is ugly about that?
> 
> Well, it's highly dependent on the internals of the interpreter, for
> starters.

Right. But if treated as an internal system tool
which is just used after understanding the
implication, there is no difference to something
like the Python interpreter itself. People who
look at it are on themselves, or they had better
not looked into it :-)

[speeup for functors, too?]

> It seems so. I've found something to do with my starship page beyond
> basic fiddling at last; go to http://starship.python.net/crew/mwh to
> find a little tarball containing closure.py from my last post and
> xapply.py. xapply.py implements functor.xapply for the simplest cases;
> it ignores varadic details and keyword arguments entirely. It does
> work for methods (bound and unbound).
> 
> I haven't timed it, but so far as I understand, it should implement
> partial argument resolution with slowdown by a factor of 1 :-).

Now, that's interesting. In all those insane speed
races, we always came up with solutions like

def my_lightspeed_impl(arg1, arg2,      None=None, map=map, ...):

to avoid global lookups. They became default values
for not otherwise used parameters.
Big Q: Is your method even faster?
Now, I did an extra benchmark and it turns out that
the old default parameter trick is still a few cycles
faster.
Possible improvements:
As you can see with my benchmark, it would be nice
to take the chance and allow to change the function
name when binding.
Then, what about indirections? I used to use default
parameter assignments like  add=operator.add
which I now would have to do elsewhere to get rid
of that indirection. Do you see a chance to bind
these through as well, maybe for builtins only, or
for surely read-only attributes?

What might the reason be for the slight slowdown
between load_const and default parameter access?
load_fast appears to be a little quicker.
Could it be even better to turn it upside down
and invent hidden default parameters instead? :-)

thanks & cheers - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home
-------------- next part --------------
# timing of Mike Hudson's binding

import closure

g1 = g2 = g3 = g4 = g5 = 0

def func1(x, g1=g1, g2=g2, g3=g3, g4=g4, g5=g5):
    return x + g1 + g2 + g3 + g4 + g5
    
def func2(x):
    return x + g1 + g2 + g3 + g4 + g5

func3 = closure.bind_now(func2)

def timing(func, args, n=1, **keywords) :
	import time
	time=time.time
	appl=apply
	if type(args) != type(()) : args=(args,)
	rep=range(n)
	before=time()
	for i in rep: res=appl(func, args, keywords)
	return round(time()-before,4), res

def test():
    for func in (func1, func2, func3):
        print func.__name__, timing(func, 42, 100000)
    
result = """
>>> test()
func1 (1.54, 42)
func2 (1.98, 42)
func2 (1.59, 42)
"""


More information about the Python-list mailing list