[ 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: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org