[infinispan-dev] trace vs log.isTraceEnabled

[Mircea Markus]

Thanks David - this is a very welcomed clarification, as current lock guarding is inconsistent and not very nice.
I've created a JIRA[1] in order to update the code and document a policy on this issue.

[1] - ISPN-1429 remove lock guards(if trace.isTraceEnbled() .. ) where possible

On 28 Sep 2011, at 17:41, David M. Lloyd wrote:

> On 09/28/2011 11:35 AM, Mircea Markus wrote:
>> Hi,
>> 
>> I'm not aware of any convention on using trace vs log.isTraceEnabled() to guard the trace statements.
>> 
>> if (trace) log.trace("some request related stuff")
>> vs
>> if (log.isTraceEnabled()) log.trace("some request related stuff");
>> 
>> The former is more efficient, but cannot be managed at runtime. It seems to be the preferred form, so shall we stick with it?
> 
> If you're using the jboss-logging API, and your log statement does not 
> do any interpolation, then it is just as fast to do any of the following 
> (with no if):
> 
>    log.trace("blah");
>    log.tracef("the %s happened to %s", foo, bar);
>    log.tracev("the {0} happened to {1}", foo, bar);
> 
> In the case where trace logging is disabled, these are exactly as 
> efficient as the if (log.isTraceEnabled()) variants.  In the case where 
> it is enabled, it is marginally more efficient (though the trace log 
> itself is substantially more expensive of course).
> 
> Overall I'd avoid the "if" forms unless you're doing complex interpolation:
> 
>    log.trace("Foo " + bar + " baz " + zap);
>    log.tracef("the %s happened to %s", fooMethod().barMethod(), bar);
> 
> ...both of which incur the expense of the expression resolution even if 
> the log message is ultimately discarded.
> -- 
> - DML
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev