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

[Markus Kohler]

>>>>> "Brian" == Brian Lloyd <Brian at digicool.com> writes:

[deltia]

    Brian> Arne,

    Brian> While I'm not going to go near comparing Python to Perl, I
    Brian> will comment that different languages are just that -
    Brian> different.  As such, the approach you would take in one
    Brian> language may not be the most appropriate (or comparable in
    Brian> speed or efficiency) to the approach you would take in
    Brian> another.

    Brian> The question here (IMHO) is not Python's appropriateness
    Brian> for processing large datasets (a fair number of
    Brian> scientist-types do this all the time), or even the speed of
    Brian> Python in general, but using the most appropriate
    Brian> algorithms in the context of the language in use.

Python would be appropriate for much more problems if it would only be as fast
as other scripting languages. The bytecode interpreter IS significantly slower
than other byte code interpreted languages. Since we all know that python 
is more productive than most other languages, this becomes sooner or later an
issue because one would not be able some tasks in python because it is just 
to slow.  

    Brian> For example, Perl is very regex-centric, so your example
    Brian> Perl implementation is probably perfectly appropriate for
    Brian> Perl. Python tends to be more optimized for the general
    Brian> case, and if it were _me_, I wouldn't bother with using
    Brian> regular expressions in this case,. Since you have a
    Brian> predictable file format, there are more specific (and
    Brian> efficient) Python tools that you could use here.

You are right that one should choose the right tool for a problem, but
I disagree that Python is optimized for the general case. Squeak a free
Smalltalk implementation (www.squeak.org), is already much faster ( about
3 times actually )  than python and it has even a true Garbage
Collector. As soon as the first Just in Time Compiler has been
finished, it may even come close to Visualworks a commercial
Smalltalk implementation with a Just in Time Compiler. At the moment
Visualworks is still at least 5 times faster than squeak. 
I tell you all this just to give you some idea how fast a language that is 
as flexible as python could be. 

    [deletia]

>From profiling python 1.5.2c I found that python's main problem is that 
calling functions seems to be very costly. Also I have not yet looked at 
this issue in detail it is obvious that the code to call a
python function is pretty complex. 

I guess this is because python supports default arguments and other
'nice' features for calling functions.  

It seems to me that without a redesign of at least the bytecode for
function calls python's speed will not take off. 

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