Return-Path: Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 34875 invoked by uid 500); 12 Aug 2003 21:01:54 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 34843 invoked from network); 12 Aug 2003 21:01:54 -0000 Message-ID: <4FE9AD0A3D28CE42A163544072FE86760286F0B7@msgsw55cacah01.wellsfargo.com> From: Eric.D.Friedman@wellsfargo.com To: axis-dev@ws.apache.org Subject: RE: isDebugEnabled calls Date: Tue, 12 Aug 2003 14:01:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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