Re: good design & method calls
In article <[EMAIL PROTECTED]>, Ron_Adam <[EMAIL PROTECTED]> wrote: >On Tue, 29 Mar 2005 09:09:37 -0500, Charles Hartman ><[EMAIL PROTECTED]> 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. >> >>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. . . . 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* 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: good design & method calls
On Tue, 29 Mar 2005 09:09:37 -0500, Charles Hartman <[EMAIL PROTECTED]> 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. > >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 -- http://mail.python.org/mailman/listinfo/python-list
Re: good design & method calls
On Mar 29, 2005, at 10:36 AM, Peter Hansen wrote: 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. :-) No, that's very helpful; thanks. Charles Hartman -- http://mail.python.org/mailman/listinfo/python-list
Re: good design & method calls
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
--
http://mail.python.org/mailman/listinfo/python-list
