jkraska1 at san.rr.com
Wed May 9 05:59:13 CEST 2001
On Wed, 09 May 2001 03:38:45 GMT, grante at visi.com (Grant Edwards) wrote:
>In article <QM%J6.96455$HF.21774089 at news4.rdc1.on.home.com>, Nick Perkins wrote:
>>Things can usually be done many ways in python, and it is
>>rarely obvious which will be fastest.
>That's an interesting observation. I don't think it's true about C -- but C
>is much lower level and an experienced programmer will have a pretty good
>idea what code the compiler will generate for various constructs (at least
>that's the case in the embedded world -- maybe it isn't for other
>Is that observation generally true of higher-level languages like Python,
>Scheme, and Smalltalk -- or is there something about Python that makes it
>uniquely difficult to guess what will be the fastest?
It's pretty easy to guess how Python's going to perform once you've
looked at a bit of how it's implemented, and groked what the various
implementation choices made by the Python designers mean to the
probable implementation in the interpreter.
Python's hard to second guess for the beginner, because it's so
abstract; a beginner wouldn't guess that the cost of concatenating
numerous strings together will be big, simply _because_ Python's
strings are all immutable and therefore massive duplication is
The good news here is that Python is _trivial_ to profile. It's just
a few lines of code. To wit:
s = pstats.Stats("profile.out")
And you're wrong about one thing: C's not as easy to guess where
the time goes as one might think. I've brought Quantify to more than
one program where the programmer spent a great deal of time
optimizing code which never amounted to more than 2% of the
execution time of the program. I've seen more than one program
that was bound almost entirely by I/O, string manipulation, and
memory allocation; in such programs, optimizing _anything else_
would have been a complete and utter waste of my time.
The moral of the story: one must always profile.
More information about the Python-list