On 09/30/2016 01:53 AM, Sebastian Laskawiec wrote:
Hey!
A while ago I asked Radim and Dan about these kind of constructs [1]:
private boolean trace = logger.isTraceEnabled(); //stored in a field
... called in some method ...
if(trace)
logger.tracef(...);
...
At first they seemed wrong to me, because if one changes logging level
(using JMX for example), the code won't notice it. I also though it's
quite ok to use tracef directly, because JIT will inline and optimize it.
Unfortunately my benchmarks [2] show that I was wrong. Logger#tracef
indeed checks if the logging level is enabled but since JBoss Logging
may use different backends, the check is not trivial and is not inlined
(at least with default settings).
What backend where you using with your test?
The performance results look like this:
Benchmark Mode Cnt Score Error Units
MyBenchmark.noVariable thrpt 20 *717252060.124* ± 13420522.229 ops/s
MyBenchmark.withVariable thrpt 20 *2358360244.627* ± 50214969.572 ops/s
So if you even see a construct like this: logger.debuf or logger.tracef
- make sure you check if the logging level is enabled (and the check
result is stored in a field).
That was a bit surprising and interesting lesson :D
Thanks
Sebastian
[1]
https://github.com/infinispan/infinispan/pull/4538#discussion_r80666086
[2]
https://github.com/slaskawi/jboss-logging-perf-test
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
- DML