Howdy, You're in a difficult position ;( My gut instinct says a map lookup will be faster than Logger.getLogger(), so your idea about populating a map might be good. Of course you will still have one Logger.getLogger() call for each logger, but that's far better than calling it every time.
You also have to enforce a convention regarding logger naming, e.g. use the class name for the logger name. That may not be a big deal, as it's a common convention anyways, but note that log4j by itself does not require this convention. Yoav Shapira Millennium ChemInformatics >-----Original Message----- >From: Wulf Wechsung [mailto:[EMAIL PROTECTED] >Sent: Wednesday, April 02, 2003 9:11 AM >To: Log4j (E-Mail) >Subject: Performance and Logger.getLogger() > > >Hey! > >I read in the faq that calling Logger.getLogger() will kill app >performance. >I am currently writing a wrapper for a beast called the SAP/webMethod >business connector which is an app-server providing a 'unique' flow >language >to programm services. It would be to quite an effort to ask the developers >of those services to keep references to their logger and pass it for each >log statement, so I would did an implementation that determines which >logger >to use by itself. Unfortunatly it has to call Logger.getLogger() for each >log-call. >The question is: would application performance be better if I kept the >Logger references in a hashtable and retrieved them from there by name? >This might seem like an unnecessary question but I just don't know how much >over-heap there is involved when calling Logger.getLogger(). > >Thanks in advance, >Wulf > >PS:"I made a serious effort to see if this has been asked before via the >mail archives, so please excuse me if it, in fact, has been" > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
