Why is Python slow? (was Re: One Python 2.1 idea)

Bjorn Pettersen pbjorn at uswest.net
Mon Dec 25 00:23:03 EST 2000


Neelakantan Krishnaswami wrote:

> On 24 Dec 2000 12:37:02 -0800, Aahz Maruch <aahz at panix.com> wrote:
> [snip]

> > One of the reasons that gets brought up less often than it should is
> > that Guido is somewhat fanatical about also keeping the CPython
> > implementation clean and simple.  I'm pretty sure that -- Ghu forbid it
> > become necessary -- I could manage to maintain CPython if I had to.
> >
> > This leaves less room for optimization than many people think.
>
> Perhaps.
>
> I started to take a look at the Ocaml 3.00 bytecode interpreter the
> other day, and it is quite clean and readable. It is also right around
> 10-20 times faster than the Python interpreter, measuring just the
> basic busy-loop. The only filips in the Ocaml interpreter that jumped
> out at me were a) some macrology to enable the gcc computed labels
> extensions when it was available, and b) it uses tagging to avoid
> allocating on the heap when handling integers.
>
> [python code]
>
> When passed n=10000000, the median runtime for loop1 was 7.05 seconds,
> and for loop2 was 3.89 seconds.
>
> Some equivalent code in Ocaml:
>
> [ocaml code]

> With n=10000000, this ran in a median of 0.4 seconds. This is the
> performance of the interpreter, mind -- Ocaml also has a compiler
> which I didn't exercise. I think this suggests there is room for
> *huge* performance improvements in interpreted Python.

You're comparing apples and oranges here. Even though both languages were
interpreted in your tests, that's pretty much where the similarity ends.
Ocaml, or any other ML, is designed so that exact type inference can be done,
thus the interpreter knows exactly which types a variable can and cannot
take. This gives the interpreter many more possibilities for safe
optimizations.

A better comparison would be with LISP or Smalltalk, both of which are
usually at least an order of magnitude faster than Python, but at the cost of
significantly more complex interpreters/compilers.

-- bjorn





More information about the Python-list mailing list