Python is slow

Andreas Kostyrka andreas at
Fri Dec 12 18:18:33 CET 2008

On Fri, Dec 12, 2008 at 06:17:43AM -0800, sturlamolden wrote:
> None of those projects addresses inefficacies in the CPython
> interpreter, except for psyco - which died of an overdose PyPy.

Bullshit. All that discussion about performance forgets that performance is a function of the whole system, not the language.

Worse you can measure it really badly.

E.g. it's relative simple to compare CPython versus IronPython versus Jython. For a given benchmark program.

As programs do not trivially translate from language A to language B, nor does fluency in language A make you automatically fluent in
language B after learning the syntax.

> PyPy is interesting if they ever will be able to produce something
> useful. They have yet to prove that. Even if PyPy can come up with a
> Python JIT, they will still be decades behind the technologies of
> Strongtalk and Java. That is the problem with reinventing the wheel
> all over again.

Well, it's reinventing the wheel. The problem that Java is a different kind of wheel 
(boxed vs. unboxed objects, plus more static compile time bindings), Smalltalk is also different (e.g. multiple inheritence),
so you need to have a specific toolbox for the wheel, sorry. Keeping and enhancing the tribal wisdom
about toolbox design is what a subtribe of the Computer Scientists do.

Btw, Psyco is not a JIT like most JVMs had them, it's a specializing compiler. JVM JITs traditionally speeded up the unboxed data 
type operations. Psyco does something comparable, but it has to specialize first on data types. The end effect is similiar, but the 
background of what happens is quite different.

> Not to forget LLVM and Parrot which also will support Python
> frontends.
When they do, they'll do. There have flown quite a bit of Python version since the time that it was announced that
Parrot will have a Python frontend.


More information about the Python-list mailing list