python simply not scaleable enough for google?
mcherm at gmail.com
Thu Nov 12 16:07:23 CET 2009
On Nov 11, 7:38 pm, Vincent Manis <vma... at telus.net> wrote:
> 1. The statement `Python is slow' doesn't make any sense to me.
> Python is a programming language; it is implementations that have
> speed or lack thereof.
> 2. A skilled programmer could build an implementation that compiled
> Python code into Common Lisp or Scheme code, and then used a
> high-performance Common Lisp compiler...
I think you have a fundamental misunderstanding of the reasons why
slow. Most of the slowness does NOT come from poor implementations:
implementation is extremely well-optimized; the Jython and Iron Python
implementations use best-in-the-world JIT runtimes. Most of the speed
come from fundamental features of the LANGUAGE itself, mostly ways in
it is highly dynamic.
In Python, a piece of code like this:
needs to watch out for the following:
* Perhaps x is a list OR
* Perhaps x is a dict OR
* Perhaps x is a user-defined type that declares a __len__
* Perhaps a superclass of x declares __len__ OR
* Perhaps we are running the built-in len() function OR
* Perhaps there is a global variable 'len' which shadows the
* Perhaps there is a local variable 'len' which shadows the
* Perhaps someone has modified __builtins__
In Python it is possible for other code, outside your module to go in
modify or replace some methods from your module (a feature called
"monkey-patching" which is SOMETIMES useful for certain kinds of
There are just so many things that can be dynamic (even if 99% of the
they are NOT dynamic) that there is very little that the compiler can
So whether you implement it in C, compile to CLR bytecode, or
Lisp, the computer is still going to have to to a whole bunch of
make certain that there isn't some monkey business going on, rather
simply reading a single memory location that contains the length of
Brett Cannon's thesis is an example: he attempted desperate measures
perform some inferences that would allow performing these
safely and, although a few of them could work in special cases, most
hoped-for improvements were impossible because of the dynamic nature
I have seen a number of attempts to address this, either by placing
restrictions on the dynamic nature of the code (but that would change
nature of the Python language) or by having some sort of a JIT
common path where we don't monkey around. Unladen Swallow and PyPy are
such efforts that I find particularly promising.
But it isn't NEARLY as simple as you make it out to be.
-- Michael Chermside
More information about the Python-list