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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev