logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Chadwick (JIRA)" <j...@apache.org>
Subject [jira] [Created] (LOG4J2-1403) Unboxer in new gc-free implementation
Date Wed, 01 Jun 2016 10:46:59 GMT
Nick Chadwick created LOG4J2-1403:

             Summary: Unboxer in new gc-free implementation
                 Key: LOG4J2-1403
                 URL: https://issues.apache.org/jira/browse/LOG4J2-1403
             Project: Log4j 2
          Issue Type: Question
          Components: API
    Affects Versions: 2.6
            Reporter: Nick Chadwick
            Priority: Minor

Firstly, thanks for the GC-free work you've done in 2.6 - it's great news, and I've already
adopted it in the project I'm currently involved with.

However, I just wanted to point out a possible wrinkle, for discussion as much as anything.
As a matter of habit, I try to surround any low-level (e.g. debug, trace) log statement that
does any processing in its parameters (i.e. calls methods, etc) with a check to .isXXXEnabled().
This means that the enabled check will run twice - once when I call it explicitly, and once
under the hood when the log statement runs. 

With the new GC-free stuff, wrapping primitives using Unbox.box() meets this criteria - I
don't really want a log statement for a disabled level using up processing power appending
to StringBuilders for all the primitive arguments to the log statement, when I'm not going
to use the results. Therefore, everywhere I have these low-level log statements that are using
Unbox.box(), I have to wrap them in enabled checks. 

Concerned that this may have an impact on performance, I am instead caching the result of
.isXXXEnabled() in a static variable on the class.

I'm just wondering whether this has been considered, and if this is the right approach?


This message was sent by Atlassian JIRA

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message