[Python-Dev] 2.4 news reaches interesting places

[Raymond Hettinger]

> One thing that bugs me: the article says 3 or 4 times that Python is
> slow, each time with a refutation ("but it's so flexible", "but it's
> fast enough") but still, they sure seem to harp on the point. This is
> a PR issue that Python needs to fight -- any ideas?

* Ask a prominent PSF member, ESR, to stop bagging on that point in his
book (python is much faster since he wrote it and Moore's law has made
it less of an issue over time).  Py1.5.2 running on a 133Mhz 386 is not
the same beast as well designed Py2.4 code running on a 3Ghz Pentium IV
(also I would argue that many apps are computationally bound anyway).


* Have python.org prominently feature an article of Python's use in
high-performance environments.  IIRC, somebody wrote a realtime voice
over internet system and found that with good design, there was no speed
issue.  Also, the cellphone apps may make a good example.


* Another prominent developer and PSF member wrote a much publicized,
unfavorable log entry basically saying that he was unimpressed with
Py2.4.  While that log entry was subsequently revised, it did serve as
anti-advocacy.  Also, my request was denied for better presentation of
performance related benchmarks in the widely read What's New document.
Right now, it features somewhat unimpressive and misleading pystone
results.  
Were we to show comparative pybench results 2.0 to 2.1 to 2.2 to 2.3 to
2.4, it would become clear that some of the performance concerns are out
of date.
Parrotbench and test_decimal also reveal some modest gains over 2.3.


* A ZDNet reporter had setup a phone interview with me but did not
follow through.  I had planned to nip the issue in the bud by focusing
on the Py2.4's vastly improved scalability:

- The trend toward use of iterators, generators, generator expressions,
and itertools scale-up well because of their superb memory performance
and ability to save state.  Apps using generators and genexps save all
the time that was formerly lost to accessing instance variables.  And
apps keying off of itertools can sometimes completely avoid interpreter
overhead.  IOW, Py2.4 provides a strong toolset for writing clean,
high-performance apps with a minimum of development time.

- Behind the scenes, almost every important building block has either
improved algorithms, memory optimizations, speed optimizations, and/or
has been rewritten in C (while still preserving their pure Python
equivalents).  The bytecodes get optimized for speed and readability,
and the eval-loop itself is tighter.  Lists initialize, append, pop, and
extend much faster and are more conservative with memory.  List comps
are up to twice as fast.  Dictionary iteration is speedier.  Sets,
bisect, and heaps now have C implementations like other basic building
blocks.  All of the fifo queues in the library now use an O(1) algorithm
instead of O(n) -- this improves scalability for everything from
threading and queues to mutexs and asynchat.


* Any PR effort should also emphasize that no usability trade-offs were
made along the way.  A number of features make Py2.4 easier to use than
1.5.6:  list comps, genexps, generators, sets, nested scopes, int/long
unification, decorators, etc.  Some might argue that it takes a modicum
effort to learn listcomps, generators, and decorators, but they cannot
make any bones about the cleanliness, simplicity, beauty, and speed of
the resulting code.  Python will always lead in maintainability and
development time.


* Python's website has traditionally been self-centered, leaving others
to have to make the case for their own products.  Perhaps, it is time to
change that.  Those who really care about speed cannot make a balanced
decision about Python without considering psyco, pyrex, numpy, and the
like as part of the total development environment.


* There is another angle that is difficult to present but a reality
never-the-less.  It is easy to write toy C / C++ code that is blazingly
fast.  However, when you add error checking, fault tolerance,
interaction with real world, etc, the code gets slower.  Also because
that code is harder to write, it is somewhat common to use crummy
algorithms (linear searches for example).  I really liked Tim's comment
that code using Python's dictionaries runs 10,000 times faster than
anything written in any other language.  That seems to get to the point
across well enough.


* A bit of good news is that the upcoming Python cookbook will make a
strong case for Py2.4 being a tool of choice for those who care speed,
space, maintainability, and development time.  It is a nice, highly
visible bit of advocacy.


* One last thought.  Articles will always pick on something.  It's not
really a terrible thing to have someone say the superb productivity
gains come at the price of running slower than C.  I would much rather
hear that than have people bag on the docs or standard library or launch
into a diatribe @decocrator destroying the beauty of the language.



Raymond