[jira] [Created] (LOG4J2-1403) Unboxer in new gc-free implementation

["Nick Chadwick (JIRA)" <ji...@apache.org>]

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?

Thanks



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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