Alexander Staubo wrote:
I definitely believe that Python is Zope's largest problem right now. It's also, from a technical point of view, one of it's biggest assets -- Zope is becoming the killer application of Python, and might eventually become the driving force to evolve Python, which is, I believe, suffering from draught into the contributor department. Skilled developers aren't flocking to Python to make it faster. Not right now, anyway.
Hm, skilled developers do hack on Python! There's the Python people at CRNI, there's Christian Tismer in Germany doing Stackless Python (which offers interesting arcane features and a mild performance improvements), there's the whole JPython group, there's John Skaller with his Vyper project (a Python interpreter/compiler in Ocaml, one of the reasons is more speed). Then there's the Python Types-SIG, which I urge you to look at if you haven't already.
My hope is that Zope will change this, because Python has possibly one of the slowest interpreters on earth. Python zealots -- and there is such a beast -- will tell you that Python's performance is less of a matter because what you sacrifice in speed you gain in power, ie. computational expressiveness through a high-level, dynamic language.
It is _less_ of a problem, but most Pythoneers are indeed interested in speeding of the language. I haven't heard of zealots who want to hold back speedups, as long as it doesn't do away with the power.
For an example of a good, Python-like, dynamic language that is also very fast, take a look at Dylan. In current implementations, Dylan is not interpreted but rather compiled to native code, but in theory there is nothing stopping anyone from writing a highly efficient Dylan interpreter. Dylan's magic comes from its use of type hints, a system which I had recognized as likely pivotal to improving Python's interpreter long before I knew of Dylan.
It'll be pretty difficult to make a beast like Zope exploit type-hints, though, I think. By the way, the Types-SIG is working on type extensions to Python, partially for performance (OPT), partially for better error checking (ERR) and partially for better documentation (DOC). See: http://www.python.org/sigs/types-sig/ And also see the new compiler SIG: http://www.python.org/sigs/compiler-sig/
In Dylan, specifying a variable's type is optional. When omitted, the Dylan compiler will usually be able to infer the type from what you do with the variable (ie., it sees you're assigning an integer to it; hence it can assume that, for at least a stretch of execution, the variable remains an integer). When you explicitly declare a variable's type, Dylan applies the necessary code optimizations (such as using tight integer maths or string copying) as well as static type checking. In Python, variables can hold virtually anything, and this incurs a huge amount of checks.
Type inference is not a simple thing to add to the language, though..
Just imagine -- while Zope is running, thousands and thousands of the same little checks are performed continuously, over and over again, amounting to no uncertain overhead.
That's of course true. I heard Christian Tismer talk about making a register machine interpreter for Python, which could potentially speed things up quite a bit. I shall ask him about this idea again sometime. :)
Python's biggest overhead comes from its dynamism -- the dynamic typing, as explained, combined the object allocation system: most things is an object, so a lot of objects are constantly spawned and torn down, often in rapid succession because the compiler/interpreter can make few hard analyses of when stuff is needed. Python also has a high function-call overhead.
All true. Anyway, the only thing you're wrong about is that Pythoneers aren't interested in improving performance. They are, but I grant you they're not performance nuts like users of C or C++. :) Regards, Martijn