wasm-demo/demo/ermis-f/python_m/cur/0245

53 lines
2.0 KiB
Plaintext
Raw Permalink Normal View History

From: wtanksle at dolphin.openprojects.net (William Tanksley)
Date: Wed, 28 Apr 1999 17:54:02 GMT
Subject: Python IS slow ! [was] Re: Python too slow for real world
References: <613145F79272D211914B0020AFF6401914DAD8@gandalf.digicool.com> <p5g15lmb35.fsf@bidra241.bbn.hp.com>
Message-ID: <slrn7ieipq.8uk.wtanksle@dolphin.openprojects.net>
Content-Length: 1583
X-UID: 245
On 28 Apr 1999 09:57:18 +0200, Markus Kohler wrote:
>>>>>> "Brian" == Brian Lloyd <Brian at digicool.com> writes:
>[deltia]
> Brian> Arne,
>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.
Your data is correct (Python is slow for many things, slower than it needs
to be), but your conclusion is wrong. Python isn't slow because its
bytecode engine is slow; actually, although there's a lot of room for
improvement, its bytecode engine is faster than many of the others out
there.
The reason it's slow is its runtime model. _Every_ function call requires
a lookup in a hash table, just on the off-chance that the programmer
changed the meaning of the function.
>It seems to me that without a redesign of at least the bytecode for
>function calls python's speed will not take off.
Bytecode won't help enough -- the whole calling model needs to be
examined. Fortunately, that's one of the things the 2.0 design process
will be looking at. Like you, I hope that they consider Smalltalk as an
example.
And Oberon (SlimBinaries), and Eiffel (typing and general compile-time
error catching), and ...
>Markus
--
-William "Billy" Tanksley
"But you shall not escape my iambics."
-- Gaius Valerius Catullus