<div dir="ltr">Hey!<div><br></div><div>Adding James to this thread.</div><div><br></div><div>@Dennis - I think Dan has a point here. The trick with checking a field in a class is 3 times faster. Most of the checks are done in core so they are executed multiple times per operation. Changing all those places is probably not an option.</div><div><br></div><div>@David - Let me run a test with JBoss Log Manager and get back to you with some results. But if Dan is right, and the problem is with enum mapping, I will get similar results.</div><div><br></div><div>Thanks</div><div>Sebastian</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 1, 2016 at 11:53 AM, Dan Berindei <span dir="ltr"><<a href="mailto:dan.berindei@gmail.com" target="_blank">dan.berindei@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Sep 30, 2016 at 10:15 PM, David M. Lloyd <<a href="mailto:david.lloyd@redhat.com">david.lloyd@redhat.com</a>> wrote:<br>
> The performance problem that this trick is meant to resolve is really a<br>
> problem in the logging backend. It *should* be faster inside of<br>
> WildFly, where JBoss LogManager is used, because that project just<br>
> checks a single volatile field for the level check... and the path to<br>
> that code *should* be inline-friendly.<br>
><br>
<br>
</span>Indeed, we started using this trick because of log4j 1.2, which needs<br>
to walk the logger hierarchy in order to check the level, and it made<br>
a significant difference there.<br>
<br>
Nowadays I think it's pretty close to optimal in all logging<br>
frameworks. The only nitpick is that they all use enums for the<br>
levels, and the JIT can't inline Level.TRACE.value as it would with a<br>
Level.TRACE_VALUE int constant. If JDK9 fixes that, then it's going to<br>
be more or less equivalent to using a volatile "trace" field in each<br>
class, so it should be suitable even for local read operations that<br>
take < 200ns.<br>
<br>
We'd probably still need to weed out some of the trace messages, as we<br>
probably have more than 10 of them during such a read operation. I<br>
confess that I added way too many trace logs myself, precisely because<br>
I knew we are using a static final field and the JIT compiler doesn't<br>
even generate code for that branch.<br>
<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888">Dan<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<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>