And it's probably good practice to have a blanket policy of _always_ have the code guard. Regardless of the logging level. Once you get passed 3 people in your team you want to simplify code conventions.
The other problem is that when you change something from error to info or something people might not realise they need to put the if in and so you might get some logging statements which are not wrapped. You want to avoid that. On 9 July 2012 11:39, Dr Heinz M. Kabutz <[email protected]> wrote: > The String is first constructed and then passed into the log() method. So > yeah, you should use code guards (if (log.isDebugEnabled()) etc.) when you > write logging statements. > > Regards > > Heinz > -- > Dr Heinz M. Kabutz (PhD CompSci) > Author of "The Java(tm) Specialists' Newsletter" > Sun Java Champion > IEEE Certified Software Development Professional > http://www.javaspecialists.eu > Tel: +30 69 75 595 262 > Skype: kabutz > > > On 7/9/12 11:55 AM, Ewald Horn 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 CTJUG-Tech+unsubscribe@** > googlegroups.com <ctjug-tech%[email protected]> > For more options, visit this group at http://groups.google.com/** > group/CTJUG-Tech?hl=en <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/ > -- see my blog: http://analysis102.blogspot.com http://audiblethoughts.blogspot.com http://outsideofficehours.blogspot.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/
