How slow? (was Re: Python IS slow !)

[Markus Kohler]

M.-A. Lemburg wrote:
> 
> Markus Kohler wrote:
> >
> > >>>>> "Gordon" == Gordon McMillan <gmcm at hypernet.com> writes:
> >
> > [deletia]
> >     Gordon> This thread is a bit unusual in being a general complaint,
> >     Gordon> based on measuring Python's function call overhead. Again,
> >     Gordon> there's some truth there, but it doesn't appear to be
> >     Gordon> based on a user's perception of slowness of an app.
> >
> > Yes the problem is that the more you do in Python the more function call overhead
> > becomes the dominating factor for the performance of Python. Of course sometimes you
> > can escape by using builtin functions or even write your own C
> > functions just to speed up things.
> >
> > I really don't want to be forced to do that because I would like to
> > write as much as possible in Python, just because it's so much more
> > productive and so much more fun.
> 
> Have you tried the P2C "compiler" ?
> 
>         http://lima.mudlib.org/~rassilon/p2c/

Yes, the speedup is not that great. As far as I can remember not more
tham 30%. 
>From what quantify tells me it's still spending a lot of time in
function calling code. 

> 
> > I was comparing it with a free Smalltalk implementation  (made by the
> > inventors of Smalltalk) because I think this is what the performance
> > should be.
> >
> > The squeak virtual machine is written in a (small)
> > subset of Smalltalk and is automatically translated to C.
> > It's amazing to see that the resulting code is still faster than most
> > comparable scripting languages.
> 
> The last conference had some papers about "compiling" byte-code
> to C... as I remember the results were not too thrilling: the
> Python function call is one single byte code and thus eliminating
> the loop doesn't give you the expected performance increase.
> 
> To enhance the function call performance, you'd probably have
> to dig very deep into the interpreter's core and change some
> concepts as well (e.g. the execution frame concept vs. C stack,
> dynamic lookups vs. variable slots). All this is doable, but not
> without breaking code.
> 
> --

I will be posting some suggestions to comp.lang.python soon.
Also I don't know thery are feasible, I think some of them could 
speed up things noticable. 

Markus
-- 
Markus Kohler  mailto:markus_kohler at hp.com