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@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@gmail.com> wrote:
On Tue, Dec 25, 2012 at 9:11 PM, Rene Nejsum <rene@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@gmail.com | Brisbane, Australia
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas