On Mon, Jun 3, 2013 at 1:12 PM, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> On Sun, Jun 2, 2013 at 6:16 PM, Jason Swails <jason.swa...@gmail.com> > wrote: > > I'm actually with RR in terms of eliminating the overhead involved with > > 'dead' function calls, since there are instances when optimizing in > Python > > is desirable. I actually recently adjusted one of my own scripts to > > eliminate branching and improve data layout to achieve a 1000-fold > > improvement in efficiency (~45 minutes to 0.42 s. for one example) --- > all > > in pure Python. The first approach was unacceptable, the second is fine. > > For comparison, if I add a 'deactivated' debugprint call into the inner > loop > > (executed 243K times in this particular test), then the time of the > > double-loop step that I optimized takes 0.73 seconds (nearly doubling the > > duration of the whole step). > > It seems to me that your problem here wasn't that the time needed for > the deactivated debugprint was too great. Your problem was that a > debugprint that executes 243K times in 0.73 seconds is going to > generate far too much output to be useful, and it had no business > being there in the first place. *Reasonably* placed debugprints are > generally not going to be a significant time-sink for the application > when disabled. Well in 'debug' mode I wouldn't use an example that executed the loop 200K times -- I'd find one that executed a manageable couple dozen, maybe. When 'disabled,' the print statement won't do anything except consume clock cycles and potentially displace useful cache (the latter being the more harmful, since most applications are bound by the memory bus). It's better to eliminate this dead call when you're not in 'debugging' mode. (When active, it certainly would've taken more than 0.73 seconds) Admittedly such loops should be tight enough that debugging statements inside the inner loop are generally unnecessary, but perhaps not always. But unlike RR, who suggests some elaborate interpreter-wide, ambiguous ignore-rule to squash out all of these functions, I'm simply suggesting that sometimes it's worth commenting-out debug print calls instead of 'just leaving them there because you won't notice the cost' :). > The easiest way to eliminate these 'dead' calls is to simply comment-out > the > > print call, but I would be quite upset if the interpreter tried to > outsmart > > me and do it automagically as RR seems to be suggesting. > > Indeed, the print function is for general output, not specifically for > debugging. If you have the global print deactivation that RR is > suggesting, then what you have is no longer a print function, but a > misnamed debug function. > Exactly. I was just trying to make the point that it is -occasionally- worth spending the time to comment-out certain debug calls rather than leaving 'dead' function calls in certain places. All the best, Jason -- Jason M. Swails Quantum Theory Project, University of Florida Ph.D. Candidate 352-392-4032
-- http://mail.python.org/mailman/listinfo/python-list
