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

[Christian Tismer]

Michael Hudson wrote:
> 
> Christian Tismer <tismer at appliedbiometrics.com> writes:
> > Michael Hudson wrote:

[big snip]

> That would be nice, and I have thought about it, but you're replacing
> 
>         LOAD_GLOBAL     ('operator')
>         LOAD_ATTR       ('add')
> 
> which is six bytes with
> 
>         LOAD_CONST      (n)
> 
> which is just three bytes. So, as I think I said earlier, you'd need
> to recompute jumps, and I haven't yet had the bloody-mindedness to get
> that to work.

I don't think so. Just replace the superfluous opcode with
a 3-byte NOOP, i.e. SET_LINENO 4711, and then...

> It'll probably happen though. Skip Montanaro has written a peephole
> optimizer for Python
> (http://www.automatrix.com/~skip/python/spam7/optimizer.html); this
> must do these manipulations, so maybe I'll have a look at that for
> inspiration.

... simply pour it through Skip's code, which should
remove all the unnecessary crap. :-)

> The similarity of the code in xapply.py and in closure.py makes me
> think that I should write some general framework for mutilating
> codestrings. Support for changing the length of the codestring is
> pretty much a must for that.

Maybe, yes. WOuld mean to break the code list into slices,
add some lables, and re-resolve them again. Looks like
not the big deal, but some work.

> > What might the reason be for the slight slowdown
> > between load_const and default parameter access?
> > load_fast appears to be a little quicker.
> 
> Poking around the source shows that a LOAD_FAST just indexes into an
> array, whereas LOAD_CONST indexes into a Python tuple. Fast, but still
> a couple of C function calls of indirection on top of LOAD_FAST.

Not true. Both evaluate to similar load insns by macro
expansion. The reason is just a continue-shortcut which
avoids a little of the error checking code outside of
the interpreter loop. But as said in another post,
it isn't worth considering, and the code which the
MS compiler emits seems to be quite arbitrary and
should better not be touched.

...

> I don't know what the implementation details of making co_consts a
> bare C array of PyObject*s would be. It wouldn't be hard, but I don't
> really think it's worth the effort.

Nor do I.
Thanks for the fun. 
Wondering how far this can continue :-)

ciao - 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