<p>My astoptimizer provides tools to really *remove* debug at compilation, so the overhead of the debug code is just null.</p>
<p>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.</p>

<p>See:<br>
<a href="https://bitbucket.org/haypo/astoptimizer">https://bitbucket.org/haypo/astoptimizer</a> </p>
<p>Victor</p>
<div class="gmail_quote">Le 25 déc. 2012 13:43, "Rene Nejsum" <<a href="mailto:rene@stranden.com">rene@stranden.com</a>> a écrit :<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I understand and agree with all your arguments on debugging.<br>
<br>
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.<br>

<br>
debug statements in our code is probably one per 10-20 lines of code.<br>
<br>
I think my main issue (and what I therefore read into the original suggestion) was the extra "if" statement at every log statement<br>
<br>
So doing:<br>
<br>
if log.debug.enabled():<br>
        log.debug( bla. bla. )<br>
<br>
Add's 5-10% extra code lines, whereas if we could do:<br>
<br>
log.debug( bla. bla )<br>
<br>
at the same cost would save a lot of lines.<br>
<br>
And when you have 43 lines in your editor, it will give you 3-5 lines more of real code to look at  :-)<br>
<br>
/Rene<br>
<br>
<br>
<br>
On Dec 25, 2012, at 1:28 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
<br>
> On Tue, Dec 25, 2012 at 9:11 PM, Rene Nejsum <<a href="mailto:rene@stranden.com">rene@stranden.com</a>> wrote:<br>
>> But if debug() was indeed NOP'able, maybe it could be done ?<br>
><br>
> If someone *really* wants to do this, they can abuse assert statements<br>
> (which will be optimised out under "-O", just like code guarded by "if<br>
> __debug__"). That doesn't make it a good idea - you most need log<br>
> messages to investigate faults in production systems that you can't<br>
> (or are still trying to) reproduce in development and integration<br>
> environments. Compiling them out instead of deactivating them with<br>
> runtime configuration settings means you can't switch them on without<br>
> restarting the system with different options.<br>
><br>
> This does mean that you have to factor in the cost of logging into<br>
> your performance targets and hardware requirements, but the payoff is<br>
> an increased ability to correctly diagnose system faults (as well as<br>
> improving your ability to extract interesting metrics from log<br>
> messages).<br>
><br>
> Excessive logging calls certainly *can* cause performance problems due<br>
> to the function call overhead, as can careless calculation of<br>
> expensive values that aren't needed.  One alternatives occasional<br>
> noted is that you could design a logging API that can accept lazily<br>
> evaluated callables instead of ordinary parameters.<br>
><br>
> However, one danger of such expensive logging it that enabling that<br>
> logging level becomes infeasible in practice, because the performance<br>
> hit is too significant. The typical aim for logging is that your<br>
> overhead should be such that enabling it in production means your<br>
> servers run a little hotter, or your task takes a little longer, not<br>
> that your application grinds to a halt. One good way to achieve this<br>
> is to decouple the expensive calculations from the main application -<br>
> you instead log the necessary pieces of information, which can be<br>
> picked up by an external service and the calculation performed in a<br>
> separate process (or even on a separate machine) where it won't affect<br>
> the main application, and where you only calculate it if you actually<br>
> need it for some reason.<br>
><br>
> Cheers,<br>
> Nick.<br>
><br>
> --<br>
> Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
</blockquote></div>