You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ak...@apache.org> on 2008/06/06 06:40:42 UTC
[Logging] Is this required if we use substitutions
Emmanuel,
I see in some places you protect calls to LOG.debug() for example with a
IS_DEBUG conditional like so:
if ( IS_DEBUG )
{
LOG.debug( "Adding the entry {} for DN = '{}'",
opContext.getEntry(), opContext.getDn().getUpName() );
}
If the {} based substitution is used, then does this not protect us from
additional String concatenation? Is the above more efficient than:
LOG.debug( "Adding the entry {} for DN = '{}'",
opContext.getEntry(), opContext.getDn().getUpName() );
Thanks,
Alex
Re: [Logging] Is this required if we use substitutions
Posted by Emmanuel Lecharny <el...@apache.org>.
Felix Knecht wrote:
>
> I'm not totally up to date about which logger is used, but for log4j
> i.e. exists also a method LOG.isDebugEnabled() to test this (it's
> probably a little bit slower as it is not static), but its
> configurable and the code should also stay in the bytecode.
In this case, the IS_DEBUG static variable is initialized with a call to
LOG.isDebugEnabled(). As I said, it is just an ultimate optimization to
allow the call to the isDebugEnabled() method to be done.
You have to know than in the decoder, this method is called for every
single byte being read from the network layer, leading to a time penalty
which is noticable. This is the reason why I switched to a static variable.
> What I don't exactly now is if the config can be changed at runtime.
yes it can, but we have to add some code in order to allow this.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [Logging] Is this required if we use substitutions
Posted by Felix Knecht <fe...@apache.org>.
Emmanuel Lecharny schrieb:
> Hi,
>
> in this very case, the DN won't be parsed, as the getUpName() just
> returns the inner String.
>
> The difference between a direct call to log.debug and the if
> (IS_DEBUG) is that if the IS_DEBUG is set to false, then the compiler
> will simply not do the test at all, because it's a static variable,
> and it will be optimized internally by a removal of this portion of
> the code.
>
> So the "is (IF_DEBUG)" will be faster than a call to the LOG.debug()
> method, sparing the call.
>
> Keep in mind that it's marginal, but in some places where we have a
> lot of LOGs, this is interesting to use this trick.
>
> Also this is valid for DEBUG mode, not for info, as it won't be
> anymore possible to activate the log dynamically without restarting
> the server, as the bytecode will not contain the call anymore.
I'm not totally up to date about which logger is used, but for log4j
i.e. exists also a method LOG.isDebugEnabled() to test this (it's
probably a little bit slower as it is not static), but its configurable
and the code should also stay in the bytecode.
What I don't exactly now is if the config can be changed at runtime.
Felix
>
> Ersin Er wrote:
>> Hi,
>>
>> I think this is more of an issue of parameter evaluation than string
>> concatenation. If you do not do a IS_DEBUG check first, then even if the
>> debug is not enabled, opContext.getEntry() and
>> opContext.getDn().getUpName()
>> will have to be evaluated first (before the debug method is called).
>> So if
>> these are particularly expensive operations you may have a serious
>> CPU cycle
>> loss. The example here is not perfect for demostrating this situation
>> but if
>> one of the parameters was calculated via a DN parsing operation then the
>> result (without IS_DEBUG) would be quite bad.
>>
>> Greetings,
>>
>> On Fri, Jun 6, 2008 at 7:40 AM, Alex Karasulu <ak...@apache.org>
>> wrote:
>>
>>
>>> Emmanuel,
>>>
>>> I see in some places you protect calls to LOG.debug() for example
>>> with a
>>> IS_DEBUG conditional like so:
>>>
>>> if ( IS_DEBUG )
>>> {
>>> LOG.debug( "Adding the entry {} for DN = '{}'",
>>> opContext.getEntry(), opContext.getDn().getUpName() );
>>> }
>>>
>>> If the {} based substitution is used, then does this not protect us
>>> from
>>> additional String concatenation? Is the above more efficient than:
>>>
>>> LOG.debug( "Adding the entry {} for DN = '{}'",
>>> opContext.getEntry(), opContext.getDn().getUpName() );
>>>
>>> Thanks,
>>> Alex
>>>
>>>
>>
>>
>>
>>
>
>
Re: [Logging] Is this required if we use substitutions
Posted by Emmanuel Lecharny <el...@apache.org>.
Hi,
in this very case, the DN won't be parsed, as the getUpName() just
returns the inner String.
The difference between a direct call to log.debug and the if (IS_DEBUG)
is that if the IS_DEBUG is set to false, then the compiler will simply
not do the test at all, because it's a static variable, and it will be
optimized internally by a removal of this portion of the code.
So the "is (IF_DEBUG)" will be faster than a call to the LOG.debug()
method, sparing the call.
Keep in mind that it's marginal, but in some places where we have a lot
of LOGs, this is interesting to use this trick.
Also this is valid for DEBUG mode, not for info, as it won't be anymore
possible to activate the log dynamically without restarting the server,
as the bytecode will not contain the call anymore.
Ersin Er wrote:
> Hi,
>
> I think this is more of an issue of parameter evaluation than string
> concatenation. If you do not do a IS_DEBUG check first, then even if the
> debug is not enabled, opContext.getEntry() and opContext.getDn().getUpName()
> will have to be evaluated first (before the debug method is called). So if
> these are particularly expensive operations you may have a serious CPU cycle
> loss. The example here is not perfect for demostrating this situation but if
> one of the parameters was calculated via a DN parsing operation then the
> result (without IS_DEBUG) would be quite bad.
>
> Greetings,
>
> On Fri, Jun 6, 2008 at 7:40 AM, Alex Karasulu <ak...@apache.org> wrote:
>
>
>> Emmanuel,
>>
>> I see in some places you protect calls to LOG.debug() for example with a
>> IS_DEBUG conditional like so:
>>
>> if ( IS_DEBUG )
>> {
>> LOG.debug( "Adding the entry {} for DN = '{}'",
>> opContext.getEntry(), opContext.getDn().getUpName() );
>> }
>>
>> If the {} based substitution is used, then does this not protect us from
>> additional String concatenation? Is the above more efficient than:
>>
>> LOG.debug( "Adding the entry {} for DN = '{}'",
>> opContext.getEntry(), opContext.getDn().getUpName() );
>>
>> Thanks,
>> Alex
>>
>>
>
>
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [Logging] Is this required if we use substitutions
Posted by Ersin Er <er...@gmail.com>.
Hi,
I think this is more of an issue of parameter evaluation than string
concatenation. If you do not do a IS_DEBUG check first, then even if the
debug is not enabled, opContext.getEntry() and opContext.getDn().getUpName()
will have to be evaluated first (before the debug method is called). So if
these are particularly expensive operations you may have a serious CPU cycle
loss. The example here is not perfect for demostrating this situation but if
one of the parameters was calculated via a DN parsing operation then the
result (without IS_DEBUG) would be quite bad.
Greetings,
On Fri, Jun 6, 2008 at 7:40 AM, Alex Karasulu <ak...@apache.org> wrote:
> Emmanuel,
>
> I see in some places you protect calls to LOG.debug() for example with a
> IS_DEBUG conditional like so:
>
> if ( IS_DEBUG )
> {
> LOG.debug( "Adding the entry {} for DN = '{}'",
> opContext.getEntry(), opContext.getDn().getUpName() );
> }
>
> If the {} based substitution is used, then does this not protect us from
> additional String concatenation? Is the above more efficient than:
>
> LOG.debug( "Adding the entry {} for DN = '{}'",
> opContext.getEntry(), opContext.getDn().getUpName() );
>
> Thanks,
> Alex
>
--
Ersin Er
http://www.ersin-er.name