Python/Scripting language performance

Fernando Pereira pereira at cis.upenn.edu
Fri May 31 20:30:59 EDT 2002


On 5/30/02 12:59 PM, in article 3CF65A62.2070705 at bioeng.ucsd.edu, "Curtis
Jensen" <cjensen at bioeng.ucsd.edu> wrote:

> I'm looking for an explicit explination of why Scripting languages,
> specificaly Python, are slow compared to compiled languages.  I've
> searched the newsgroup and bit on the web.  I'm looking for a more
> indepth description other than because it's dynamic, or it's object
> oriented, or it's interpreted.  Specificaly why do those aspects make it
> slower?
The main reason, which is independent of whether is interpreted, byte-code
compiled, or compiled into machine language, is that in those languages the
decision of what piece of machine code implements a particular language
operation has to be delayed until the operands are known. For example, in C
or Java, for the fragment

    int x, y, z;
    ...
    z = x + y;

the compiler can figure out that "+" is to be implemented by the target
machine's integer addition instruction, so there is no decision to make at
runtime.

In Python, the expression

    z = x + y

may evaluate as integer addition, floating point addition,
arbitrary-precision integer addition, sequence concatenation, or even a
method call on the object bound to x depending on the types of the values
that are bound to x and y when the expression is evaluated. Therefore,
Python must execute machine code to examine the types of the arguments of +
and dispatch to the appropriate method, which takes far more time than just
computing the integer addition if that is what is required by the types of x
and y. Notice that this does not depend on whether the language is
interpreted or compiled: in a hypothetical compiled Python, a lot of machine
instructions would be included to do those tests (which would make the
compiled code very bulky, a good reason for not compiling Python to machine
language in the first place). In an interpreted or byte-code compiled, the
interpreter or the implementations of the byte-code virtual instructions
take care of those tests.

I gave the x + y example, but similar issues arise in mapping any symbol to
a concrete machine implementation, for instance, in figuring out what "f"
means in

    x.f(y)

because mapping symbols to methods requires looking up the current value of
the slot "x" in the method dictionary for the current object bound to x. In
Java, say, the mapping is somewhat more direct (not quite immediate because
of virtual methods, though).

Similar comments apply to other languages with late binding of code
fragments to operator names, such as Perl or Scheme.

-- F


-- F






More information about the Python-list mailing list