I tend to agree with Ravi on this one. I have also used this pattern before
and seen the results of log.debug on performance in other applications. it
makes a lot of sense. Doing the if-statement check typically is only one
instruction in the VM, and it short circuits the operations inside that
block if log.isDebugEnabled() is false. This is probably not much of a
difference when logging some static String that is externed.
i.e. this is probably OK:
log.debug("some static message");
however, what I think we all want to avoid is things like this:
log.debug("the value is " + someIntensiveCalculation());
it is easy to just use the if(log.isDebugEnabled) statement around anything
that does a calculation (even concatenating large static Strings can have a
significant performance/memory impact if it gets executed enough times).
However, as Van points out, we have bigger fish to fry, so let's not go
through and look for all of these places, but just be opportunistic about
adding an if statement around them when we do come across potentially
expensive log messages (anything not static).
thanks,
Sam
On Thu, Feb 21, 2008 at 12:23 PM, Adam Monsen <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-02-21 at 17:01 +0000, Ravi Kutaphale wrote:
> > About the conditional logs, I somehow dont agree with you that it will
> > decrease code readability. When traversing a code most of us do
> > ignore the log statement. so
> > if(log.isDebugEnabled) {
> > log.debug("some exception trace");
> > }
> >
> > will be similar for developer as :
> >
> > log.debug("some exception trace");
> >
> > But will definately improve runtime performance by avoiding string
> > creation.
>
> Interesting!
>
> I'm also leaning away from the 3-line form of the debug statement (as a
> matter of personal preference in terms of readability and writability),
> but it would be interesting to see--after version 1.1 is released--just
> how big a win this might be in terms of performance.
>
> I've worked on other systems where we enclosed logging statements in
> similar conditional blocks, but I never really questioned why.
>
> --
> Adam Monsen
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
