I think it is highly unlikely that you would ever want to set the logging level to FATAL on a live server, or even to anything below the level of INFO. So for debugging I think it is worth the extra check of isDebugEnabled() as the String manipulation is costly.
IMO I'm not convinced it is worth doing this for ERROR level logging though as I don't know why you would not want this level of logging in a live application. As far as using another logging framework, logback appears to be the new log4j (http://logback.qos.ch/reasonsToSwitch.html). AFAIK Log4j has been inactive for quite a while. Like you say in your mail, I'm not sure its worth the change of framework unless the cost benefits out way the cost of changing so much old code. If performance is an issue, a POC could persuade the powers that be, that a framework change is needed. Cheers Chris On 9 July 2012 10:55, Ewald Horn <[email protected]> wrote: > Hi. > > Quick question regarding logging and effort around making it more > effective and less intrusive. > > I'm working on older code bases where LOG4J is being used as a logger. > It works great, but I believe there are some performance penalties > hidden in the usage pattern. This is of course difficult to prove on a > single machine without writing extensive test cases, but I have the > following coding pattern: > > For ALL logging statements that are run at DEBUG level, and that > concatenate a String object, I put a wrapper (isDebugEnabled()) around > them to avoid the String concatenation where possible. This makes > sense as it's a common practice when using LOG4J. Same obviously goes > for INFO level events, with the isInfoEnabled() method. From what I > can tell from small JUnit tests, this does seem to make a difference > over many iterations that simulate the behaviour of a server > application. > > Now I'm looking at a code base where the developers have cleverly > written a bunch of logging statements using the ERROR level logging > feature, for example, logger.error("The current user is : " + USER_ID > + " " + USER_NAME) - just an example, not actual code. The idea is > that they only want this information if ERROR level logging is > enabled, which I fully understand. Surely these should be wrapped in a > isEnabledFor() call as well though, as they will still incur the same > penalties that a DEBUG or INFO level logging call will have. This is > easy to verify by just examining the source code for LOG4J. > > Has anyone done any real checking regarding this? I know there are > other logging frameworks, but I can't motivate a switch to a new > logger, but I think a revisit of the current logging statements are in > order as these String concatenations must surely add up to something > expensive over the lifetime of an application? Or is it a case of too > much effort for too little gain? I'm wondering if it's worth the > effort to start the long debate about this, and to fight for the time > to update hundreds of logging statements. A case study or two would go > a long way towards building a convincing argument that this is a > better standard in the long run. > > Best regards, > Ewald > > -- > You received this message because you are subscribed to the Google Groups > "CTJUG Tech" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/CTJUG-Tech?hl=en > For Cape Town Java User Group home page see http://www.ctjug.org.za/ > For jobs see http://jobs.gamatam.com/ -- You received this message because you are subscribed to the Google Groups "CTJUG Tech" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/CTJUG-Tech?hl=en For Cape Town Java User Group home page see http://www.ctjug.org.za/ For jobs see http://jobs.gamatam.com/
