+1, definitely.
> -----Original Message-----
> From: Eric.D.Friedman@wellsfargo.com
> [mailto:Eric.D.Friedman@wellsfargo.com]
> Sent: Tuesday, August 12, 2003 5:02 PM
> To: axis-dev@ws.apache.org
> Subject: RE: isDebugEnabled calls
>
>
> 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:steve_l@iseran.com]
> Sent: Tuesday, August 12, 2003 1:53 PM
> To: axis-dev@ws.apache.org
> Subject: Re: isDebugEnabled calls
>
>
> Eric.D.Friedman@wellsfargo.com 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
>
|