Re^2: Balancing Logging and Code Readability

Here is a performance tip for you:
use constant DEBUG => 1;
print "this is debug" if DEBUG;
[download]

While this is all well and fine, it can't be changed in run-time. Log::Log4perl has a mechanism is_level that allows for reasonably high performance while allowing configuration changes in run-time (init_and_watch).

$logger->debug("Erroneous array: @super_long_array")
  if($logger->is_debug());
[download]

Benchmark your code and see if you can live with the penalty. Performance is not everything.

--
No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them. [1]

Comment on Re^2: Balancing Logging and Code Readability Select or Download Code

Replies are listed 'Best First'.
Re^3: Balancing Logging and Code Readability by Marshall (Canon) on Sep 23, 2009 at 08:58 UTC
Performance is not everything. Quite true! When you make a logging file, you have to think about how big can it get? And how and when to you "clean it up?". I have log files that I "prune" once per month or even once per year! I have applications where I tell the users to turn on some .cfg flags when they are having troubles. My goal is to get enough info so that I can replicate their problem on my machine. Ok, now that I can replicate the problem, I am in my development environment (super fancy!:, ie Textpad). I can turn on debug things that would otherwise "just bomb" the user system in terms of the shear amount of output. So there are reasons for this "turn on option x, requires changing the code" other than just execution performance, turning some option on might generate so much output that that in itself causes a problem. I allow log options in the ".cfg" file that will be helpful to me in replicating the problem. I have other other options in the code that I use to debug the problem and find out "why".	[reply]

Replies are listed 'Best First'.

Re^3: Balancing Logging and Code Readability
by Marshall (Canon) on Sep 23, 2009 at 08:58 UTC

Performance is not everything.

When you make a logging file, you have to think about how big can it get? And how and when to you "clean it up?".

I have log files that I "prune" once per month or even once per year!

I have applications where I tell the users to turn on some .cfg flags when they are having troubles. My goal is to get enough info so that I can replicate their problem on my machine.

Ok, now that I can replicate the problem, I am in my development environment (super fancy!:, ie Textpad). I can turn on debug things that would otherwise "just bomb" the user system in terms of the shear amount of output.

So there are reasons for this "turn on option x, requires changing the code" other than just execution performance, turning some option on might generate so much output that that in itself causes a problem. I allow log options in the ".cfg" file that will be helpful to me in replicating the problem. I have other other options in the code that I use to debug the problem and find out "why".

[reply]