good design & method calls

[Charles Hartman]

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.

Charles Hartman
Professor of English, Poet in Residence
the Scandroid is at: http://cherry.conncoll.edu/cohar/Programs
http://villex.blogspot.com

 

[Peter Hansen]

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

 

[Ron_Adam]

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.

Charles Hartman
Professor of English, Poet in Residence
the Scandroid is at: http://cherry.conncoll.edu/cohar/Programs
http://villex.blogspot.com

It depends...

Converting small functions to inline, usually should only be done in
the inner most loops to optimize performance if it's needed. Moving
calculations out of those loops by doing them ahead of time is also
good.

It's good practice in python to put all of your code in functions or
class's even if it's a single main() function.

def main()
(program code)

main()

Then you avoid the slower globals unless you declare them with the
global statement.

If main, or any other functions, get too big or complex, split them up
as needed.

Ron

 

[Cameron Laird]

It depends...

Converting small functions to inline, usually should only be done in
the inner most loops to optimize performance if it's needed. Moving
calculations out of those loops by doing them ahead of time is also
good.

It's good practice in python to put all of your code in functions or
class's even if it's a single main() function.

def main()
(program code)

main()

Then you avoid the slower globals unless you declare them with the
global statement.

If main, or any other functions, get too big or complex, split them up
as needed.

.
.
.
I follow-up in part for the opportunity to address a Poet-in-residence.

I don't understand the claim that, "These two pieces of advice imply
opposite ..." actions. In any case, I urge you to adopt the rule:
when in doubt, write a function (or method). If you hesitate at all,
that's evidence that you'll eventually be thankful you invested the
effort explicitly to name a function (or method).

Also, I strongly recommend to you the *Python Cookbook* <URL:
http://www.oreilly.com/catalog/pythoncook2/ >. Make sure you get the
second edition. It will delight you more than you imagined a computing
book could.

I applaud Ron's advice to define a main(). As soon as possible, I also
want you to learn the "if __name__ == '__main__':", doctest, and pydoc
idioms; I suspect you'll find them all invaluable.