print statements and profiling a function slowed performance

[Michael Torrie]

On 06/26/2014 12:44 PM, CM wrote:
> Huh. I learned two new Python facts this week:
> 
> 1. print statements were slowing down my code enough to
> really notice a particular transition. It went from about
> 2-3 seconds to a bit under 1 second. What at first seemed
> unresponsive now seems almost snappy. The only difference
> was removing a lot of print statements I had used for
> debugging (Python 2.5, on a single core 1.97 Ghz machine).

Yes print statements are very useful, but you have to be careful with
them.  In Uni I remember working on a project where we coded up an
algorithm, and then attempted to work out by timing the O() runtime of
the algorithm.  Wanting to be fancy and print out a progress report, I
added an entire term to the O() runtime!  Instead of O(log n), it became
closer to O(n).  Oops!

Seems like over the years good old fashioned debugging skills have been
lost.  In the earliest days of IDEs (Turbo BASIC and QuickBASIC) I
regularly would employ debuggers with break points, watches, and step
through my code.  Nowadays it seems we loath to fire up the debugger.  I
imagine the currently available debugger frontends like ddd or kdbg
support pdb.  Not sure though.

> 2. Merely having a cPython decorator for profiling a 
> function significantly slowed down performance...again,
> from a about 2 seconds to just under a second (~1 second
> doesn't seem much but these sorts of delays do affect 
> user experience).  There is something ironic or 
> Heisenbergian about that.

Yes, it stands to reason that profiling code is going to introduce a
runtime cost.  How else would we expect profiling to work?  That's why a
production "release" is done with debugging and profiling stuff removed.
 What I do find Heisenbergian are bugs that show up when debugging and
profiling stuff are removed, but completely gone when present.  IE
profiling and debugging slow it down enough that often subtle race
conditions are masked.