[Python-ideas] Dynamic code NOPing

[Rene Nejsum]

I understand and agree with all your arguments on debugging.

At my company we typically make some kind of backend/server control software, with a LOT of debugging lines across many modules. We have 20+ debugging flags and in different situations we enable a few of those, if we were to enable all at once it would defently have an impact on production, but hopefully just a hotter CPU and a lot of disk space being used.

debug statements in our code is probably one per 10-20 lines of code.

I think my main issue (and what I therefore read into the original suggestion) was the extra "if" statement at every log statement

So doing:

if log.debug.enabled():
	log.debug( bla. bla. )

Add's 5-10% extra code lines, whereas if we could do:

log.debug( bla. bla )

at the same cost would save a lot of lines.

And when you have 43 lines in your editor, it will give you 3-5 lines more of real code to look at  :-)

/Rene



On Dec 25, 2012, at 1:28 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Tue, Dec 25, 2012 at 9:11 PM, Rene Nejsum <rene at stranden.com> wrote:
>> But if debug() was indeed NOP'able, maybe it could be done ?
> 
> If someone *really* wants to do this, they can abuse assert statements
> (which will be optimised out under "-O", just like code guarded by "if
> __debug__"). That doesn't make it a good idea - you most need log
> messages to investigate faults in production systems that you can't
> (or are still trying to) reproduce in development and integration
> environments. Compiling them out instead of deactivating them with
> runtime configuration settings means you can't switch them on without
> restarting the system with different options.
> 
> This does mean that you have to factor in the cost of logging into
> your performance targets and hardware requirements, but the payoff is
> an increased ability to correctly diagnose system faults (as well as
> improving your ability to extract interesting metrics from log
> messages).
> 
> Excessive logging calls certainly *can* cause performance problems due
> to the function call overhead, as can careless calculation of
> expensive values that aren't needed.  One alternatives occasional
> noted is that you could design a logging API that can accept lazily
> evaluated callables instead of ordinary parameters.
> 
> However, one danger of such expensive logging it that enabling that
> logging level becomes infeasible in practice, because the performance
> hit is too significant. The typical aim for logging is that your
> overhead should be such that enabling it in production means your
> servers run a little hotter, or your task takes a little longer, not
> that your application grinds to a halt. One good way to achieve this
> is to decouple the expensive calculations from the main application -
> you instead log the necessary pieces of information, which can be
> picked up by an external service and the calculation performed in a
> separate process (or even on a separate machine) where it won't affect
> the main application, and where you only calculate it if you actually
> need it for some reason.
> 
> Cheers,
> Nick.
> 
> -- 
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia