Yep, that's the idea. The difference is that the dynamically altered changes will only show up on new messages after the point where the change appears. So every instance of DeserializationContextImpl (for example) would have an instance variable with the value of isDebugEnabled. It would use that value for its entire lifecycle, which == one request/response loop.
Eric -----Original Message----- From: Steve Loughran [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 1:53 PM To: [EMAIL PROTECTED] Subject: Re: isDebugEnabled calls [EMAIL PROTECTED] wrote: > My profiling shows that an appreciable amount of time is spent on > isDebugEnabled calls. It's not huge, but they add up to 5 seconds of time > over 100 calls because they are invoked almost 400,000 times in over those > 100 calls. > > I'm wondering whether we couldn't adopt the policy that says debug logging > is either enabled or disabled at creation time for certain heavily used > objects, like DeserializationContextImpl. So, you'd either get debug > logging or you wouldn't, on a message by message basis. Changes won't take > effect until the next message. DeserializationContextImpl accounts for > almost all of the calls described above. > > I am, of course, volunteering to do the work. What say you? > > Eric I say that assuming people are just using static log4j config, then this is a definite performance boost. My only concern is for live tuning of production servers, those in which you suddenly want to turn on diagnostics for a bit without a restart. If the changes you make can still get picked up between messages, i.e. on a live system without a restart, then I am for it. -steve
