As you yourself noted, a major problem with the compile-time elimination of logging (debug or other) is that it then becomes impossible to enable same at run time. You don't really appreciate that ability until you've had to use it -- even once -- to diagnose a production problem.
Another problem with compile-time eliminiation of logging is the possibility that correct behavior of the code is dependent on a side-effect of some part of the logging code. This is very bad style, of course, and no one would ever recommend doing it. But it happens nevertheless. If your test organization uses a "development" compilation then their tests might run just fine. The defect would only manifest itself in the "production" build where logging code was optimized away. My recommendation would be to reduce logging overhead for debug and info levels (the most likely levels to be disabled) using the enabled methods referred to in a previous message on this thread. The majority of overhead to logging when a level is disabled has to do with parameter construction which can be quite costly as in the case that several Strings are being concatenated to obtain the final message content. Checking whether the level is enabled eliminates this costly parameter value setup. Best regards, Jim Cakalic > -----Original Message----- > From: Edward Q. Bridges [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 18, 2002 8:57 AM > To: Log4J Users List > Subject: RE: Performance of log4j > > > instead of using the method isDebugEnabled() at every > occurence of a debugging > statement, we have a final static boolean variable > DEBUG_ENABLED in a base class > which is initialized (once) by a call to logger.isDebugEnabled(). > > the advantages of this are twofold: first, you're not doing > a method invocation for > every debug statement in order to test whether or not > debugging is enabled. second, > when we release the code in production, we can assign a > literal false value to the > code and recompile. this renders all debugging statements > "unreachable" and > compiles them out of the code altogether. of course, this > would prevent switching to > debugging level at runtime to get detailed info on the system > without recompiling. > > a similar arrangement can be done with isInfoEnabled(). > > HTH > --e-- > > > On Thu, 18 Apr 2002 09:10:44 -0400, Shapira, Yoav wrote: > > > meaningful stuff and not logging too much. Definitely use > > logger.isDebugEnabled() for debug messages, as that could > be a nearly > > > -- > Edward Q. Bridges > http://www.teachscape.com > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> >
