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

--
- DML

_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev