[Python-ideas] Dynamic code NOPing

[Victor Stinner]

My astoptimizer provides tools to really *remove* debug at compilation, so
the overhead of the debug code is just null.

You can for example declare your variable project.config.DEBUG as constant
with the value 0, where project.config is a module. So the if statement in
"from project.config import DEBUG ... if DEBUG: ..." will be removed.

See:
https://bitbucket.org/haypo/astoptimizer

Victor
Le 25 déc. 2012 13:43, "Rene Nejsum" <rene at stranden.com> a écrit :

> 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
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20121230/06d9f83c/attachment.html>