Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Is this overkill (logging) ?

 
Linus Nikander
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
On my current project the coding guidelines mandate that we surround all log calls with (with the proper log-level ofcourse):

if (log.isTraceEnabled()) {
log.trace("Inside initLocationLists");
}

the motivation for the guideline is that if the logstatement includes any argument that has to evaluated first ( say log.trace("Value a = " + methodcallA(inputA)) ), then that methodcall will be made even though the loglevel is higher than the threshold for that particular log-statement. And because it will be evaluated we will incurr a performance penalty all the time regardless of loglevel.

Even though I can understand the reasoning I still feel that its a bit overkill, and worse that it clutters the code. What are your opinions ?

//Linus Nikander
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would just do
log.trace("foobar!");
and let the logging framework handle the log level. The method call is dirt-cheap -- it's the write operation to disk that makes logging so darn expensive.
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Linus Nikander:
On my current project the coding guidelines mandate that we surround all log calls [...] Even though I can understand the reasoning I still feel that its a bit overkill, and worse that it clutters the code. What are your opinions ?
Quite simple. Greater minds than yours, mine or the people who came up with coding guidelines have found that premature optimisation is the root of all evil in programming. In 99% of the code, the time taken by logging statements is totally irrelevant. The if statement is just so much clutter wasting development and maintenance effort. In the remaining 1%, having shown log message construction overhead to be significant (for example using a profiler), by all means do enclose the logging in an if statement.

- Peter

PS. The 99% and 1% are totally fictitious, of course, but I believe they do convey the right impression.
 
Linus Nikander
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Lasse Koskela:
I would just do
log.trace("foobar!");
and let the logging framework handle the log level. The method call is dirt-cheap -- it's the write operation to disk that makes logging so darn expensive.


I was actually referring to that which is passed TO the log.trace call, not the actual evaluation of if the call qualiifies for logging or not. For example in log.trace("trace " + this.veryHeavyMethodToExecute() ); it's the call to this.veryHeavyMethodToExecute() which could potentially incurr the penalty since it will always be evaluated before the call to .trace is made.

As far as I understood your answer you were referring to the .trace call.

Anyway, I'm still on your side Just have to convince my boss somehow.

//Linus
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ah. If this is a single incident, by all means go ahead and enclose the trace() call. Generally, however, I'm with Peter's premature optimization point of view (as you are as well, apparently).
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic