<div dir="ltr">Yes, exactly - Radim is correct.<div><br></div><div>I added also one test - &quot;if(logger.isTraceEnabled()) logger.trace(...)&quot;. The results look like the following:</div><div><div>Benchmark                             Mode  Cnt           Score         Error  Units</div><div>MyBenchmark.noVariable               thrpt   20   725265655.062 ± 1777607.124  ops/s</div><div><b>MyBenchmark.withIsTraceEnabledCheck  thrpt   20   725116016.785 ± 2812327.685  ops/s</b></div><div>MyBenchmark.withVariable             thrpt   20  2415571350.540 ± 7052276.025  ops/s</div></div><div><br></div><div>Both results (logger.tracef(...) and if(logger.isTraceEnabled()) logger.tracef(...)) look exactly the same. This is expected because logger.tracef checks if proper level is enabled before processing input.</div><div><br></div><div>Thanks</div><div>Sebastian</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 30, 2016 at 10:36 AM, Radim Vansa <span dir="ltr">&lt;<a href="mailto:rvansa@redhat.com" target="_blank">rvansa@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Wolf, the isTraceEnabled() is called only once during class<br>
initialization (if that&#39;s a static field) or instance creation, but it<br>
is usually stored as final field and therefore the JVM is likely to<br>
optimize the calls.<br>
<br>
It&#39;s possible to change final fields, and in this case it&#39;s not as<br>
unsafe (the only risk is not logging something and the cost related to<br>
recompiling the class), but the problematic part is finding them :) In<br>
Infinispan, you get close to all logging if you inspect all classes in<br>
component registry (and global component registry). It&#39;s not as easy as<br>
setting the level through JMX, though.<br>
<br>
R.<br>
<span class=""><br>
On 09/30/2016 09:43 AM, Wolf Fink wrote:<br>
&gt; I understand the impact of this, but we should keep in mind that there<br>
&gt; are some important points where it is worse if you can&#39;t change the<br>
&gt; logging on the fly for a few moments to check something and switch back.<br>
&gt;<br>
&gt; For the test my understanding is that you use<br>
&gt; - the logger.tracef direct<br>
&gt; - check logger.isTraceEnabled() first<br>
&gt;<br>
&gt; I see the variable stored but not used - or am I wrong and the<br>
&gt; benchmark test do something extra?<br>
&gt;<br>
&gt;<br>
&gt; So interesting would be the difference between<br>
&gt; - log.trace(&quot;xyz&quot;)<br>
&gt; - if(log.isTraceEnabled) log.trace(&quot;xyz&quot;)<br>
&gt; - log.tracef(&quot;xyz %s&quot;, var)<br>
&gt; - if(log.isTraceEnabled) log.tracef(&quot;xyz %s&quot;,var)<br>
&gt; and the construct with storing the log level in a static field<br>
&gt; - boolean isTrace=log.isTraceEnabled()<br>
&gt;    if(isTrace) log.tracef(&quot;xyz %s&quot;,var)<br>
&gt;<br>
&gt;<br>
&gt; On Fri, Sep 30, 2016 at 8:53 AM, Sebastian Laskawiec<br>
</span><span class="">&gt; &lt;<a href="mailto:slaskawi@redhat.com">slaskawi@redhat.com</a> &lt;mailto:<a href="mailto:slaskawi@redhat.com">slaskawi@redhat.com</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;     Hey!<br>
&gt;<br>
&gt;     A while ago I asked Radim and Dan about these kind of constructs [1]:<br>
&gt;<br>
&gt;     private boolean trace = logger.isTraceEnabled(); //stored in a field<br>
&gt;<br>
&gt;     ... called in some method ...<br>
&gt;         if(trace)<br>
&gt;             logger.tracef(...);<br>
&gt;     ...<br>
&gt;<br>
&gt;     At first they seemed wrong to me, because if one changes logging<br>
&gt;     level (using JMX for example), the code won&#39;t notice it. I also<br>
&gt;     though it&#39;s quite ok to use tracef directly, because JIT will<br>
&gt;     inline and optimize it.<br>
&gt;<br>
&gt;     Unfortunately my benchmarks [2] show that I was wrong.<br>
&gt;     Logger#tracef indeed checks if the logging level is enabled but<br>
&gt;     since JBoss Logging may use different backends, the check is not<br>
&gt;     trivial and is not inlined (at least with default settings). The<br>
&gt;     performance results look like this:<br>
&gt;     Benchmark                  Mode  Cnt Score          Error  Units<br>
</span>&gt;     MyBenchmark.noVariable    thrpt   20 *717252060.124* ±<br>
&gt;     13420522.229  ops/s<br>
&gt;     MyBenchmark.withVariable  thrpt   20 *2358360244.627* ±<br>
<span class="">&gt;     50214969.572  ops/s<br>
&gt;<br>
&gt;     So if you even see a construct like this: logger.debuf or<br>
&gt;     logger.tracef - make sure you check if the logging level is<br>
&gt;     enabled (and the check result is stored in a field).<br>
&gt;<br>
&gt;     That was a bit surprising and interesting lesson :D<br>
&gt;<br>
&gt;     Thanks<br>
&gt;     Sebastian<br>
&gt;<br>
&gt;     [1]<br>
&gt;     <a href="https://github.com/infinispan/infinispan/pull/4538#discussion_r80666086" rel="noreferrer" target="_blank">https://github.com/infinispan/<wbr>infinispan/pull/4538#<wbr>discussion_r80666086</a><br>
&gt;     &lt;<a href="https://github.com/infinispan/infinispan/pull/4538#discussion_r80666086" rel="noreferrer" target="_blank">https://github.com/<wbr>infinispan/infinispan/pull/<wbr>4538#discussion_r80666086</a>&gt;<br>
&gt;     [2] <a href="https://github.com/slaskawi/jboss-logging-perf-test" rel="noreferrer" target="_blank">https://github.com/slaskawi/<wbr>jboss-logging-perf-test</a><br>
&gt;     &lt;<a href="https://github.com/slaskawi/jboss-logging-perf-test" rel="noreferrer" target="_blank">https://github.com/slaskawi/<wbr>jboss-logging-perf-test</a>&gt;<br>
&gt;<br>
&gt;     ______________________________<wbr>_________________<br>
&gt;     infinispan-dev mailing list<br>
</span>&gt;     <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a> &lt;mailto:<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.<wbr>jboss.org</a>&gt;<br>
&gt;     <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/infinispan-<wbr>dev</a><br>
&gt;     &lt;<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/infinispan-<wbr>dev</a>&gt;<br>
<span class="im HOEnZb">&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; infinispan-dev mailing list<br>
&gt; <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/infinispan-<wbr>dev</a><br>
<br>
<br>
</span><span class="HOEnZb"><font color="#888888">--<br>
Radim Vansa &lt;<a href="mailto:rvansa@redhat.com">rvansa@redhat.com</a>&gt;<br>
JBoss Performance Team<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/infinispan-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>