A better self
Michael Chermside
mcherm at destiny.com
Tue Jul 23 09:15:26 EDT 2002
> (1) t, x, y, z=self.t, self.x, self.y, self.z
[...]
> (2)t=self.t; x=self.x; y=self.y; z=self.z;
[...]
> I still prefer (1) -- most readable, but I like minimum overhead.
Then I recomend that you avoid Python.
Seriously, Python is interpreted, and the overhead for performing a
simple mathematical calculation like
sin(t) * x**y + sqrt(z)
in Python vs doing it directly in C, Fortran, or some other
close-to-the-machine language is FAR, FAR greater than the difference
between (1) and (2) above.
Think about it like this. Suppose there were two ways to write your
code. Method (A) was clear and easy to read, and not particularly
difficult to modify. Method (B) was much harder to read, and a real pain
to modify. But method (B) runs X microseconds faster.
If X makes the difference between your whole program running in 5
minutes vs 5 hours, or the difference between your user interface
responding in 0.5 seconds vs locking for 5 seconds, then you probably
care deeply, and you probably want to use method (B). If X makes the
difference between your whole program running in 5 minutes vs 6 minutes,
or the user interface responding in 0.3 seconds or 0.5 seconds, then
many programmers would prefer method (A).
If you are one of those who would choose method (B) even when the
difference in runtime was between 5 and 6 minutes, then you probably
shouldn't be using Python. Yes, Python is a nice language, and yes, it
can be sped up by recoding key portions of an application in C/C++, but
it is never going to be as fast as an algorithm hand coded in assembly.
I guess what I'm trying to say here is, yes... having the functions
separate WILL slow things down, and by a *LOT* more than the difference
between (1) and (2) above. But you REALLY shouldn't be worrying about
the difference in execution time between (1) and (2)... if you ARE
worrying about such things, then there are MUCH bigger gains to be had
by trying a different kind of language.
-- Michael Chermside
More information about the Python-list
mailing list