Charles Hartman wrote:
I know the answer to this is going to be "It depends . . .", but I want
to get my mind right. In Fowler's *Refactoring* I read: "Older languages
carried an overhead in subroutine calls, which deterred people from
small methods" (followed by the basic "Extract Method" advice). In Skip
Montanaro's "Python Performance Tips"
(http://manatee.mojam.com/~skip/python/fastpython.html) I read: ". . .
use local variables wherever possible. If the above loop is cast as a
function, append and upper become local variables. Python accesses local
variables much more efficiently than global variables."
These two pieces of advice imply opposite kinds of code revisions.
Obviously they have different purposes, and both are right at different
times. I wonder if anyone has some wisdom about how to think about when
or how often to do which, how to balance them ultimately, and so on.
While I don't see that Skip's specific comment in any way
implies that one should not write functions (doesn't it
*say* to write a function?), you are correct at least in
the implication that Fowler's advice about creating lots
of small functions can carry a performance cost in Python.
Python functions have a relatively high setup overhead.
On the other hand, most of refactoring is or should be
focused on improving the structure of code (removing
duplication, improving readability, generalizing, etc)
and *not* on improving performance. Why "should be?"
Because in general focusing on improving performance is
wasted effort, often with negative results when you
look at the big picture.
I suspect you've seen the repeated comments in this
comp.lang.python about premature optimization ("the
root of all evil in programming" etc. etc.).
Optimization rarely *improves* code readability, and
often involves a decrease in generality or other
tradeoffs. If it conflicts this much with advice
from the refactoring world, you'd do well to pay
close attention to *why* you are trying to change
your code. If it's for performance reasons, then
don't pay a lot of attention to the Fowler stuff.
Otherwise ignore things like Skip's comment above,
and focus on making the code readable.
The thing that has helped me most in writing efficient
Python is to remember that *I'm using Python*, and
it's already rather slower than C for many of the
things I do. Why am I using Python? Not for speed,
clearly, so worrying about speed is probably a little
silly. I use Python because of the readability,
because I can write it about ten times faster than
I can write in other languages, and because I have
access to such a wide array of outstanding libraries
that someone else has already optimized. So in
the end, my definition of "efficient" gets revised,
I lower my standards to the point where my current
code is "plenty fast", and I pay attention to the
other things Skip says :-) but don't spend a lot of
time trying hard to use local variables unless it
makes my code more readable in some way.
Sorry for the rant... I didn't intend it to head
that way when I started out, but I seem to be on a
bit of an anti-optimization bent today. :-)
-Peter
