You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Ashish Jain <as...@yahoo.com> on 2003/02/11 18:26:50 UTC

IsDebugEnabled

All, 

I am looking at the log4j documentation and it states the following

"To avoid the parameter construction cost write:       

if(logger.isDebugEnabled() {
        logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
      }"

I do want to avoid the parameter construction cost, but I don't want to check for IsXXXEnabled everytime I use a log statement because it makes my code clumsy. Is there a better way of doing this ? Is there a config flag  somewhere ? or should I extend the logger classes and check for IsXXXenabled before calling the Log4j classes. And then my code can call my log4jextended classes. Again, I don't want to check for IsXXXEnabled every time I use a log statement.

Any help is appreciated.

Thks,

- Ashish.



---------------------------------
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day

Re: IsDebugEnabled

Posted by Ashish Jain <as...@yahoo.com>.
I wasn't suggesting to change the logger classes but more like a wrapper....that will make the check and call the logger classes. This will allow me to have a little cleaner application code.
 
 
 Daniel Serodio <da...@checkforte.com.br> wrote:Calling isDebugEnabled() will avoid the cost of calculating ``"Entry
number: " + i + " is " + String.valueOf(entry[i])''. There's no other
way of avoiding this cost, because if you make this check inside logger,
the JVM will create this concatenated String, pass this to the logger,
which will then throw it away. But it will have been created already.

Also, you will tipically only check isDebugEnabled(), but not
isInfoEnabled(), etc. Use it only when you're concatenating many
strings, or calling (directly or indirectly) an expensive toString()
method.

Hope this helps,
Daniel Serodio

On Tue, 2003-02-11 at 15:26, Ashish Jain wrote:
> All, 
> 
> I am looking at the log4j documentation and it states the following
> 
> "To avoid the parameter construction cost write: 
> 
> if(logger.isDebugEnabled() {
> logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
> }"
> 
> I do want to avoid the parameter construction cost, but I don't want to check for IsXXXEnabled everytime I use a log statement because it makes my code clumsy. Is there a better way of doing this ? Is there a config flag somewhere ? or should I extend the logger classes and check for IsXXXenabled before calling the Log4j classes. And then my code can call my log4jextended classes. Again, I don't want to check for IsXXXEnabled every time I use a log statement.
> 
> Any help is appreciated.
> 
> Thks,
> 
> - Ashish.
> 
> 
> 
> ---------------------------------
> Do you Yahoo!?
> Yahoo! Shopping - Send Flowers for Valentine's Day
-- 
Daniel Serodio 
CheckForte


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org



---------------------------------
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day

Re: IsDebugEnabled

Posted by Daniel Serodio <da...@checkforte.com.br>.
Calling isDebugEnabled() will avoid the cost of calculating ``"Entry
number: " + i + " is " + String.valueOf(entry[i])''. There's no other
way of avoiding this cost, because if you make this check inside logger,
the JVM will create this concatenated String, pass this to the logger,
which will then throw it away. But it will have been created already.

Also, you will tipically only check isDebugEnabled(), but not
isInfoEnabled(), etc. Use it only when you're concatenating many
strings, or calling (directly or indirectly) an expensive toString()
method.

Hope this helps,
Daniel Serodio

On Tue, 2003-02-11 at 15:26, Ashish Jain wrote:
> All, 
> 
> I am looking at the log4j documentation and it states the following
> 
> "To avoid the parameter construction cost write:       
> 
> if(logger.isDebugEnabled() {
>         logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
>       }"
> 
> I do want to avoid the parameter construction cost, but I don't want to check for IsXXXEnabled everytime I use a log statement because it makes my code clumsy. Is there a better way of doing this ? Is there a config flag  somewhere ? or should I extend the logger classes and check for IsXXXenabled before calling the Log4j classes. And then my code can call my log4jextended classes. Again, I don't want to check for IsXXXEnabled every time I use a log statement.
> 
> Any help is appreciated.
> 
> Thks,
> 
> - Ashish.
> 
> 
> 
> ---------------------------------
> Do you Yahoo!?
> Yahoo! Shopping - Send Flowers for Valentine's Day
-- 
Daniel Serodio <da...@checkforte.com.br>
CheckForte


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org


Re: IsDebugEnabled

Posted by Fergus Gallagher <Fe...@OrbisUK.com>.
Generally I would pass the Logger as an argument - which makes it even uglier.


On Tue, Feb 11, 2003 at 10:45:49AM -0800, Ashish Jain wrote:
> 
> Fergus, 
> Help me understand more of what you are doing ? How/Where  do you get the handler to the logger  (Logger.getLogger(....)) to be able to control the level at run time. Do you call your own debug method from inside your code ?
> Thks,
> - Ashish. 
>  Fergus Gallagher <Fe...@OrbisUK.com> wrote:Yes, this a hard one.
> 
> One option we've used is to wrap MessageFormat
> 
> debug("Hello {1}", obj)
> 
> with cases for 1..n args and a catch-all 
> 
> debug("Hello {1}.....", new Object[] {a,b,.....});
> 
> with 
> 
> void debug(String fmt, Object arg) {
> if (LOG.isDebugEnabled()) {
> LOG.debug(MessageFormat.format(fmt, new Object[] {arg});
> }
> }
> 
> etc. 
> 
> However, this doesn't cope with "expensive" method calls:
> 
> debug("", obj.someSlowMethod());
> 
> In this case it's probably best to wrap with isDebugEnabled() yourself. A
> (messy) alternative is to use introspection:
> 
> debug(fmt, obj, "someSlowMethod");
> 
> so that obj.someSlowMethod is only evaluated if really required. Yuck.
> 
> 
> 
> On Tue, Feb 11, 2003 at 12:33:07PM -0500, John Guthrie wrote:
> > i think the rule is not to check *every time*, but only if the statement you
> > are sending to the debugger is expensive to create. our rule of thumb is to
> > check if the message requires more than one string concatenation. so for
> > this:
> > logger.debug("look out!");
> > or this:
> > logger.debug("look "+"out!");
> > there is no need to check. but beyond that, you should, because otherwise
> > you could be wasting time creating messages that don't get logged.
> > 
> > john
> > 
> > ----- Original Message -----
> > From: "Ashish Jain" 
> > To: 
> > Sent: Tuesday, February 11, 2003 12:26 PM
> > Subject: IsDebugEnabled
> > 
> > 
> > >
> > > All,
> > >
> > > I am looking at the log4j documentation and it states the following
> > >
> > > "To avoid the parameter construction cost write:
> > >
> > > if(logger.isDebugEnabled() {
> > > logger.debug("Entry number: " + i + " is " +
> > > String.valueOf(entry[i]));
> > > }"
> > >
> > > I do want to avoid the parameter construction cost, but I don't want to
> > > check for IsXXXEnabled everytime I use a log statement because it makes
> > > my code clumsy. Is there a better way of doing this ? Is there a config
> > > flag somewhere ? or should I extend the logger classes and check for
> > > IsXXXenabled before calling the Log4j classes. And then my code can call
> > > my log4jextended classes. Again, I don't want to check for IsXXXEnabled
> > > every time I use a log statement.
> > >
> > > Any help is appreciated.
> > >
> > > Thks,
> > >
> > > - Ashish.
> > >
> > >
> > >
> > > ---------------------------------
> > > Do you Yahoo!?
> > > Yahoo! Shopping - Send Flowers for Valentine's Day
> > >
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: log4j-user-help@jakarta.apache.org
> 
> -- 
> Fergus Gallagher Tel: +44 (20) 8742 1600
> Orbis Fax: +44 (20) 8742 2649
> 414 Chiswick High Street email: Fergus.Gallagher@orbisuk.com
> London W4 5TL Web: http://www.orbisuk.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-user-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------
> Do you Yahoo!?
> Yahoo! Shopping - Send Flowers for Valentine's Day
-- 
Fergus Gallagher          Tel: +44 (20) 8742 1600
Orbis                     Fax: +44 (20) 8742 2649
414 Chiswick High Street  email: Fergus.Gallagher@orbisuk.com
London  W4 5TL            Web: http://www.orbisuk.com

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org


Re: IsDebugEnabled

Posted by Ashish Jain <as...@yahoo.com>.
Fergus, 
Help me understand more of what you are doing ? How/Where  do you get the handler to the logger  (Logger.getLogger(....)) to be able to control the level at run time. Do you call your own debug method from inside your code ?
Thks,
- Ashish. 
 Fergus Gallagher <Fe...@OrbisUK.com> wrote:Yes, this a hard one.

One option we've used is to wrap MessageFormat

debug("Hello {1}", obj)

with cases for 1..n args and a catch-all 

debug("Hello {1}.....", new Object[] {a,b,.....});

with 

void debug(String fmt, Object arg) {
if (LOG.isDebugEnabled()) {
LOG.debug(MessageFormat.format(fmt, new Object[] {arg});
}
}

etc. 

However, this doesn't cope with "expensive" method calls:

debug("", obj.someSlowMethod());

In this case it's probably best to wrap with isDebugEnabled() yourself. A
(messy) alternative is to use introspection:

debug(fmt, obj, "someSlowMethod");

so that obj.someSlowMethod is only evaluated if really required. Yuck.



On Tue, Feb 11, 2003 at 12:33:07PM -0500, John Guthrie wrote:
> i think the rule is not to check *every time*, but only if the statement you
> are sending to the debugger is expensive to create. our rule of thumb is to
> check if the message requires more than one string concatenation. so for
> this:
> logger.debug("look out!");
> or this:
> logger.debug("look "+"out!");
> there is no need to check. but beyond that, you should, because otherwise
> you could be wasting time creating messages that don't get logged.
> 
> john
> 
> ----- Original Message -----
> From: "Ashish Jain" 
> To: 
> Sent: Tuesday, February 11, 2003 12:26 PM
> Subject: IsDebugEnabled
> 
> 
> >
> > All,
> >
> > I am looking at the log4j documentation and it states the following
> >
> > "To avoid the parameter construction cost write:
> >
> > if(logger.isDebugEnabled() {
> > logger.debug("Entry number: " + i + " is " +
> > String.valueOf(entry[i]));
> > }"
> >
> > I do want to avoid the parameter construction cost, but I don't want to
> > check for IsXXXEnabled everytime I use a log statement because it makes
> > my code clumsy. Is there a better way of doing this ? Is there a config
> > flag somewhere ? or should I extend the logger classes and check for
> > IsXXXenabled before calling the Log4j classes. And then my code can call
> > my log4jextended classes. Again, I don't want to check for IsXXXEnabled
> > every time I use a log statement.
> >
> > Any help is appreciated.
> >
> > Thks,
> >
> > - Ashish.
> >
> >
> >
> > ---------------------------------
> > Do you Yahoo!?
> > Yahoo! Shopping - Send Flowers for Valentine's Day
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-user-help@jakarta.apache.org

-- 
Fergus Gallagher Tel: +44 (20) 8742 1600
Orbis Fax: +44 (20) 8742 2649
414 Chiswick High Street email: Fergus.Gallagher@orbisuk.com
London W4 5TL Web: http://www.orbisuk.com

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org



---------------------------------
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day

Re: IsDebugEnabled

Posted by Fergus Gallagher <Fe...@OrbisUK.com>.
Yes, this a hard one.

One option we've used is to wrap MessageFormat

        debug("Hello {1}", obj)

with cases for 1..n args and a catch-all 

        debug("Hello {1}.....", new Object[] {a,b,.....});

with 

        void debug(String fmt, Object arg) {
                if (LOG.isDebugEnabled()) {
                        LOG.debug(MessageFormat.format(fmt, new Object[] {arg});
                }
        }

etc. 

However, this doesn't cope with "expensive" method calls:

       debug("", obj.someSlowMethod());

In this case it's probably best to wrap with isDebugEnabled() yourself.  A
(messy) alternative is to use introspection:

        debug(fmt, obj, "someSlowMethod");

so that obj.someSlowMethod is only evaluated if really required.   Yuck.



On Tue, Feb 11, 2003 at 12:33:07PM -0500, John Guthrie wrote:
> i think the rule is not to check *every time*, but only if the statement you
> are sending to the debugger is expensive to create. our rule of thumb is to
> check if the message requires more than one string concatenation. so for
> this:
>   logger.debug("look out!");
> or this:
>   logger.debug("look "+"out!");
> there is no need to check. but beyond that, you should, because otherwise
> you could be wasting time creating messages that don't get logged.
> 
> john
> 
> ----- Original Message -----
> From: "Ashish Jain" <as...@yahoo.com>
> To: <lo...@jakarta.apache.org>
> Sent: Tuesday, February 11, 2003 12:26 PM
> Subject: IsDebugEnabled
> 
> 
> >
> > All,
> >
> > I am looking at the log4j documentation and it states the following
> >
> > "To avoid the parameter construction cost write:
> >
> > if(logger.isDebugEnabled() {
> >         logger.debug("Entry number: " + i + " is " +
> > String.valueOf(entry[i]));
> >       }"
> >
> > I do want to avoid the parameter construction cost, but I don't want to
> > check for IsXXXEnabled everytime I use a log statement because it makes
> > my code clumsy. Is there a better way of doing this ? Is there a config
> > flag  somewhere ? or should I extend the logger classes and check for
> > IsXXXenabled before calling the Log4j classes. And then my code can call
> > my log4jextended classes. Again, I don't want to check for IsXXXEnabled
> > every time I use a log statement.
> >
> > Any help is appreciated.
> >
> > Thks,
> >
> > - Ashish.
> >
> >
> >
> > ---------------------------------
> > Do you Yahoo!?
> > Yahoo! Shopping - Send Flowers for Valentine's Day
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-user-help@jakarta.apache.org

-- 
Fergus Gallagher          Tel: +44 (20) 8742 1600
Orbis                     Fax: +44 (20) 8742 2649
414 Chiswick High Street  email: Fergus.Gallagher@orbisuk.com
London  W4 5TL            Web: http://www.orbisuk.com

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org


Re: IsDebugEnabled

Posted by John Guthrie <jg...@psynapsetech.net>.
i think the rule is not to check *every time*, but only if the statement you
are sending to the debugger is expensive to create. our rule of thumb is to
check if the message requires more than one string concatenation. so for
this:
  logger.debug("look out!");
or this:
  logger.debug("look "+"out!");
there is no need to check. but beyond that, you should, because otherwise
you could be wasting time creating messages that don't get logged.

john

----- Original Message -----
From: "Ashish Jain" <as...@yahoo.com>
To: <lo...@jakarta.apache.org>
Sent: Tuesday, February 11, 2003 12:26 PM
Subject: IsDebugEnabled


>
> All,
>
> I am looking at the log4j documentation and it states the following
>
> "To avoid the parameter construction cost write:
>
> if(logger.isDebugEnabled() {
>         logger.debug("Entry number: " + i + " is " +
> String.valueOf(entry[i]));
>       }"
>
> I do want to avoid the parameter construction cost, but I don't want to
> check for IsXXXEnabled everytime I use a log statement because it makes
> my code clumsy. Is there a better way of doing this ? Is there a config
> flag  somewhere ? or should I extend the logger classes and check for
> IsXXXenabled before calling the Log4j classes. And then my code can call
> my log4jextended classes. Again, I don't want to check for IsXXXEnabled
> every time I use a log statement.
>
> Any help is appreciated.
>
> Thks,
>
> - Ashish.
>
>
>
> ---------------------------------
> Do you Yahoo!?
> Yahoo! Shopping - Send Flowers for Valentine's Day
>


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org


Re: IsDebugEnabled

Posted by Ashish Jain <as...@yahoo.com>.
 
One of the cases that we have is to call  (overridden) toString()  method on our value classes. I concluded that I should be using the isXXXEnabled before doing this as a good practice. Do you concur ? I understand that I might not need it for small objects. But in general, I should be doing it ? 
Thanks for your help.
- Ashish.
 Scott Schram <sc...@schram.net> wrote:At 11:26 AM 2/11/2003, you wrote:

>All,
>
>I am looking at the log4j documentation and it states the following
>
>"To avoid the parameter construction cost write:
>
>if(logger.isDebugEnabled() {
> logger.debug("Entry number: " + i + " is " + 
> String.valueOf(entry[i]));
> }"
>
>I do want to avoid the parameter construction cost, but I don't want to 
>check for IsXXXEnabled everytime I use a log statement because it makes my 
>code clumsy. Is there a better way of doing this ? Is there a config 
>flag somewhere ? or should I extend the logger classes and check for 
>IsXXXenabled before calling the Log4j classes. And then my code can call 
>my log4jextended classes. Again, I don't want to check for IsXXXEnabled 
>every time I use a log statement.
>
>Any help is appreciated.
>
>Thks,
>
>- Ashish.

In practice, there are very few places where the parameter construction 
cost slows down your application enough to notice.

We don't log inside loops that are executed millions of times.

Also, they're talking about things where it is very time consuming to build 
the string you're trying to log, not just adding a few strings 
together. An example would be some giant object that is getting turned 
into a string, or logging something that makes a database call.

Scott


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org



---------------------------------
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day

Re: IsDebugEnabled

Posted by Scott Schram <sc...@schram.net>.
At 11:26 AM 2/11/2003, you wrote:

>All,
>
>I am looking at the log4j documentation and it states the following
>
>"To avoid the parameter construction cost write:
>
>if(logger.isDebugEnabled() {
>         logger.debug("Entry number: " + i + " is " + 
> String.valueOf(entry[i]));
>       }"
>
>I do want to avoid the parameter construction cost, but I don't want to 
>check for IsXXXEnabled everytime I use a log statement because it makes my 
>code clumsy. Is there a better way of doing this ? Is there a config 
>flag  somewhere ? or should I extend the logger classes and check for 
>IsXXXenabled before calling the Log4j classes. And then my code can call 
>my log4jextended classes. Again, I don't want to check for IsXXXEnabled 
>every time I use a log statement.
>
>Any help is appreciated.
>
>Thks,
>
>- Ashish.

In practice, there are very few places where the parameter construction 
cost slows down your application enough to notice.

We don't log inside loops that are executed millions of times.

Also, they're talking about things where it is very time consuming to build 
the string you're trying to log, not just adding a few strings 
together.  An example would be some giant object that is getting turned 
into a string, or logging something that makes a database call.

Scott


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org