[ https://issues.apache.org/jira/browse/LOG4J2-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14936424#comment-14936424 ]
Ralph Goers commented on LOG4J2-1125: ------------------------------------- First, I agree that we need to make a change. However, doing so will be very difficult since it is a static member of PatternLayout and will be re-used on a re-configuration, so it can't be cleaned up simply by a stop - it has to be done during shutdown. Second, the only time this is really a problem in a servlet container is if hot deployment is supported, which I would never expect to see in a production server. That said, I believe it could be possible to see similar problems in an OSGi container, but I am not sure about that. Remko, ContextAnchor has a ThreadLocal. It would seem to me that it would be a simple matter to change that from being a ThreadLocal<LoggerContext> to a ThreadLocal<Map<String, Object>> or, if you prefer, ThreadLocal<Map<String, Retrievable>> where Retrievable contains the Class and the Object reference. In any case, I believe the ContextAnchor is already being cleaned up at shutdown so leveraging that for things we want to store on a per thread basis seems to make sense to me. > Reuse StringBuilder to improve performance for PatternLayout > ------------------------------------------------------------ > > Key: LOG4J2-1125 > URL: https://issues.apache.org/jira/browse/LOG4J2-1125 > Project: Log4j 2 > Issue Type: Improvement > Components: Layouts > Affects Versions: 2.3 > Reporter: Remko Popma > Assignee: Remko Popma > Fix For: 2.4 > > > As part of the investigation for LOG4J2-930 (PatternLayout performance), I > found that in PatternLayout.toSerializable(), instead of creating a new > StringBuilder each time this method is called, caching and reusing a > ThreadLocal<StringBuilder> makes a huge difference in performance. > *Before (new StringBuilder instance for each event)* > {code} > Benchmark Mode Samples > Score Error Units > o.a.l.l.p.j.PatternLayoutComparisonBenchmark.log4j2 sample 125646 > 1413.362 ± 33.806 ns/op > o.a.l.l.p.j.PatternLayoutComparisonBenchmark.logback sample 128680 > 1383.201 ± 33.076 ns/op > {code} > *After (reuse ThreadLocal<StringBuilder>)* > {code} > Benchmark Mode Samples > Score Error Units > o.a.l.l.p.j.PatternLayoutComparisonBenchmark.log4j2 sample 156816 > 1138.547 ± 20.290 ns/op > o.a.l.l.p.j.PatternLayoutComparisonBenchmark.logback sample 127978 > 1355.166 ± 19.462 ns/op > {code} > org.apache.logging.log4j.PerformanceComparison results indicate this improves > overall performance: > *Before (new StringBuilder instance for each event)* > {code} > Log4j : 1501 > Logback : 1208 > Log4j 2.0: 1646 > ############################################### > Log4j : 1487 > Logback : 1165 > Log4j 2.0: 1566 > ############################################### > Log4j : 1490 > Logback : 1170 > Log4j 2.0: 1485 > ############################################### > Log4j : 1392 > Logback : 1143 > Log4j 2.0: 1629 > {code} > *After (reuse ThreadLocal<StringBuilder>)* > {code} > Log4j : 1498 > Logback : 1202 > Log4j 2.0: 1213 > ############################################### > Log4j : 1394 > Logback : 1057 > Log4j 2.0: 1290 > ############################################### > Log4j : 1240 > Logback : 1109 > Log4j 2.0: 1335 > ############################################### > Log4j : 1310 > Logback : 1146 > Log4j 2.0: 1210 > {code} > There are more changes for LOG4J2-930, so I am splitting off this item into a > separate ticket so I can address it and close it. -- 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