[Python-3000] Premature optimization and all that (original) (raw)

Guido van Rossum guido at python.org
Tue Aug 29 23:51:17 CEST 2006

Over lunch with Neal we came upon the topic of optimization and Python 3000.

It is our strong opinion that in this stage of the Py3k project we should focus on getting the new language spec and implementation feature-complete, without worrying much about optimizations.

We're doing major feature-level surgery, e.g. int/long unification, str/unicode unification, range/xrange unification, keys() views, and many others. Keeping everything working is hard work in and of itself; having to keep it as fast as it was through all the transformations just makes it that much harder.

if Python 3.0 alpha 1 is twice as slow as 2.5, that's okay with me; we will have another year to do performance measurements and add new optimizations in the ramp-up for 3.0 final. Even if 3.0 final is a bit slower than 2.5 it doesn't bother me too much; we can continue the tweaks during the 3.1 and 3.2 development cycle.

Note: I'm note advicating wholesale proactive removal of optimizations. However, I'm allowing new features to slow down performance temporarily while we get all the features in place. I expect that the optimization possibilities and needs will be different than for 2.x, since some of the fundamental data types will be so different.

In particular, I hope that Martin's int/long unification code can land ASAP; it's much better to have this feature landed in the p3yk branch, where everyone can bang on it easily, and learn how this affects user code, even if it makes everything twice as slow. This seems much preferable over having it languish in a separate branch until it's perfect.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list