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