As a side note, if you are using Jalopy (a Java code formatter from http://jalopy.sourceforge.net) it can insert those "log.isDebugEnabled()" checks for you.
J > -----Original Message----- > From: Sean Reilly [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 18, 2002 2:40 PM > To: Log4J Developers List > Subject: RE: Large Memory usage while using log4j > > > FYI: > > you can do the same with Info and Warn (or any other level) > > if (log.isInfoEnabled()) > { > ... > } > > and > > if (log.isEnabledFor(org.apache.log4j.Level.WARN)) > { > ... > } > > These checks are a good idea if you would conceivably disable > a certain logging level, and the method arguments take > runtime effort to construct. > > Depending on how often it occurs, JVM specifics, and the size > of the strings involved, string concatenation can be a big > deal for both memory and performance. > > If you want to eliminate this as a possible cause for sure, > try writing a test. Create a small program that logs a > concatenated string a large number of times. Try it with > logging enabled/disabled, and your config. Then modify the > test to perform the appropriate check and retry with logging > enabled/disabled. The data should tell you if the change is > significant. > > Sean > > > -----Original Message----- > From: James Gallogly [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 18, 2002 3:24 PM > To: Log4J Developers List > Subject: RE: Large Memory usage while using log4j > > > > That is true for our debug level logging, however we > also have info level > and warn levels that utilize string concatenation. We do > understand we are > paying for the string concatenation of the function call and > thus creating > several transient string objects that will be destroyed after > the function > call returns. This however should cause performance > implications with a > small memory cost. The concern is we are seeing a tremendous > memory cost > even though our log4j settings are configured to log nothing. > > We use this logging scheme because we have several > levels of deployment. > During development test cases are run with debug level, > during Official > Testing we run at a level of Info or Warn, and crank it up to debug if > needed (by category), during Release we set our logging to > error (which for > us is the same as none). In general our ideology has been one > of robustness > and maintainability come before performance however an order > of magnitude > memory increase/decrease is something that captures our attention. > > Jim > > -----Original Message----- > From: Sean Reilly [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 18, 2002 4:00 PM > To: Log4J Developers List > Subject: RE: Large Memory usage while using log4j > > > Just to sanity check.... > > if you log a message that performs string concatenation, you > do it like > this, right? > > (assumes an org.apache.log4j.Logger instance log) > > if (log.isDebugEnabled()) > { > log.debug("Test Log Message: " + foo + " = " + bar + "."); > } > > Sean > > Sean Reilly > Programmer, Point2 Technologies, Inc. > (306) 955-1855 > [EMAIL PROTECTED] > > > > -----Original Message----- > From: James Gallogly [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 18, 2002 2:55 PM > To: Log4J Developers List > Subject: RE: Large Memory usage while using log4j > > > > Thanks!! That is a good thread, what concerns me the > most however is that > nothing is being logged. > > Our logging was set to error (we do no error level > logging). This means > that nothing is logged in either case.... does this mean that > the Conversion > Pattern is applied before the decision to log or not occurs? > In other words > why is log4j using up so much memory to do what should be nothing? > > Thanks, > Jim > > > -----Original Message----- > From: Ceki Gulcu [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 18, 2002 3:42 PM > To: Log4J Developers List > Subject: Re: Large Memory usage while using log4j > > > > The following thread might be relevant: > > http://marc.theaimsgroup.com/?l=log4j-dev&m=103366188809758&w=2 > > > > At 15:35 18.12.2002 -0500, you wrote: > > > On my project we have been heavily utilizing log4j > as our logging > > solution. > >Recently we ran our code under very heavy load so as part of our > >optimization we wrote code to extract the log4j logging > calls from our > >source. We did this in hopes of reducing some of the overhead of > >concatenation strings together thus squeezing out some > performance gain. > > > > Much to our surprise the greatest impact was in > memory usage, our > > memory > >usage went from 1 gig to 100 meg. This order of magnitude decrease in > >resource usage caught our attention to say the least. How > might we be miss > >using the log4j tool to cause such large memory consumption? > > > > We are performing small scale experiments trying to > duplicate the > > essence > >of the problem but have had little success so far. Any help > or direction > >will be much appreciated. > > > >Thanks, > >Jim > > -- > Ceki > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> **************************************************************************** * READER BEWARE: Unencrypted, unsigned Internet e-mail is inherently insecure. Internet messages may be corrupted, incomplete, misdirected or may incorrectly identify the sender. Therefore, nothing in this message or attachments may be considered legally binding. THIS MESSAGE IS ONLY INTENDED FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY BE PRIVILEGED. If you are not the intended recipient or their authorized agent, you may not forward or copy this information and must delete or destroy all copies of this message and attachments received. If you have received this communication in error, please notify Matrikon Inc. by telephone at (780) 448-1010. **************************************************************************** *
