[
https://issues.apache.org/jira/browse/LOG4J2-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma resolved LOG4J2-1403.
---------------------------------
Resolution: Not A Problem
Resolving this issue as Not A Problem. Please feel free to re-open if you have
additional questions, or close if your concerns have been addressed.
> 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: [email protected]
For additional commands, e-mail: [email protected]
