2011/5/5 Martin Cooper <mart...@apache.org>:
> On Wed, May 4, 2011 at 9:32 PM, Lukasz Lenart
> <lukasz.len...@googlemail.com> wrote:
>> Hi,
>>
>> I've removed the parts where concatenating was over constants -
>> constant message plus constant as a string. I'm pretty sure that the
>> modern JIT compilers would optimize that as well. And the code is more
>> readable IMHO.
>> Another thing, debug(), info(), etc checks if the given log level is
>> set up or not and then performs logging (IO request, sending e-mail,
>> etc). So, it will not affect performance as well (except if there is a
>> bug ;-) )
>
> Not true. In order to call the method in the first place, all of the
> arguments must be evaluated.
>
> If you do this, the expensive function will _always_ be invoked,
> whether 'info' level logging is enabled or not:
>
>    log.info("And the answer is: " + doSomethingExpensive());

log.info("And the answer is: " + DO_SOMETHING_CONSTANT_STRING) will be
optimized by JIT and that's why I've removed logging gates. There
wasn't any call to a method and object concatenation.

> However, if you guard it, like this, the expensive function is _only_
> evaluated when the guard is passed:
>
>    if (log.isInfoEnabled()) {
>        log.info("And the answer is: " + doSomethingExpensive());
>    }
>

Yes, I agree, but it wan't the case.

> The usual argument I've seen for getting rid of the guards is that
> most of the calls don't do anything expensive, so there's little
> reason to guard them. However, it's far too easy for someone else to
> come along later and modify the log message without thinking about it
> perhaps now needing a guard, because it's now more expensive than it
> used to be. Better, then, to always guard rather than kill performance
> later by accident.

That's why I prefer a code review like this and discussion over it
instead of a common rule that we should blindly follow. Because rule
don't teach how to be a good programmer, discussion do. And if someone
did something that can impact performance, asking and explaining is
far better, than saying we have a rule. Because quite often what was
true for Java 1.4, isn't for 1.5 any more.


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
Warszawa JUG conference - Confitura http://confitura.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org

Reply via email to