Hey! Adding James to this thread.
@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. @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. Thanks Sebastian On Sat, Oct 1, 2016 at 11:53 AM, Dan Berindei <dan.berin...@gmail.com> wrote: > On Fri, Sep 30, 2016 at 10:15 PM, David M. Lloyd <david.ll...@redhat.com> > wrote: > > The performance problem that this trick is meant to resolve is really a > > problem in the logging backend. It *should* be faster inside of > > WildFly, where JBoss LogManager is used, because that project just > > checks a single volatile field for the level check... and the path to > > that code *should* be inline-friendly. > > > > Indeed, we started using this trick because of log4j 1.2, which needs > to walk the logger hierarchy in order to check the level, and it made > a significant difference there. > > Nowadays I think it's pretty close to optimal in all logging > frameworks. The only nitpick is that they all use enums for the > levels, and the JIT can't inline Level.TRACE.value as it would with a > Level.TRACE_VALUE int constant. If JDK9 fixes that, then it's going to > be more or less equivalent to using a volatile "trace" field in each > class, so it should be suitable even for local read operations that > take < 200ns. > > We'd probably still need to weed out some of the trace messages, as we > probably have more than 10 of them during such a read operation. I > confess that I added way too many trace logs myself, precisely because > I knew we are using a static final field and the JIT compiler doesn't > even generate code for that branch. > > Cheers > Dan > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
