74 lines
3.1 KiB
Plaintext
74 lines
3.1 KiB
Plaintext
From: markus_kohler at hp.com (Markus Kohler)
|
|
Date: 28 Apr 1999 09:57:18 +0200
|
|
Subject: Python IS slow ! [was] Re: Python too slow for real world
|
|
References: <613145F79272D211914B0020AFF6401914DAD8@gandalf.digicool.com>
|
|
Message-ID: <p5g15lmb35.fsf@bidra241.bbn.hp.com>
|
|
Content-Length: 2820
|
|
X-UID: 903
|
|
|
|
>>>>> "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
|
|
|
|
|
|
|
|
|