where python is slower?
Brett g Porter
BgPorter at NOartlogicSPAM.com
Wed Feb 5 17:03:36 CET 2003
"Cameron Laird" <claird at lairds.com> wrote in message
news:v42c6i91bo6n93 at corp.supernews.com...
> I feel compelled to add that there have been many real-life
> cases in which custom-coded C-based applications focused on
> text manipulation have turned out to be *slower* than their
> Python correspondents, because the latter so often employ
> superior algorithms.
In Michael Abrash's excellent (but currently out of print) book "The Zen of
Code Optimization", he goes through the process of developing several
different versions of the 'same' code, using different design, algorithm,
and optimization approaches. He tackles it from the POV of a C programmer
tempted to dip down to assembly for a speed gain, and shows that the effect
of choosing an appropriate algorithm outweighs any potential benefits gained
by going to a lower level ("faster") language (sneer quotes intentional). He
describes one of his attempts in assembler as 'the world's fastest slow
program', executing a slow algorithm as quickly as the CPU can manage.
The one line that has stuck with me since I read it is "The best optimizer
in the world is between your ears."
And, as Tim Peters has said many times in these parts, one big benefit of
Python over C is that you can write and discard bunches of algorithms that
aren't adequate for whatever reason before you get the first C
implementation working. Except that I'm sure there was some fractional
winkage in there someplace.
More information about the Python-list