[infinispan-dev] if (trace) logger.tracef - it makes sense

[Sebastian Laskawiec]

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.berindei at gmail.com>
wrote:

> On Fri, Sep 30, 2016 at 10:15 PM, David M. Lloyd <david.lloyd at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20161003/ac48b09e/attachment.html