[ 
https://issues.apache.org/jira/browse/LOG4J2-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14938781#comment-14938781
 ] 

Remko Popma commented on LOG4J2-1125:
-------------------------------------

[~dmitri_blinov] Any kind of pooling has to be either a ThreadLocal or else a 
custom implementation that uses Threads as keys. Tomcat's 
[PageContext|https://tomcat.apache.org/tomcat-8.0-doc/config/systemprops.html] 
pool is also a ThreadLocal.

In our case, if we make the field non-static, we would only create a new 
ThreadLocal instance when Log4j is reconfigured. The previous ThreadLocal 
instance associated with the PatternLayout of the previous configuration will 
no longer be referenced and can be garbage collected. These instances will not 
accumulate because they are stored in the ThreadLocalMap in WeakReferences.

> 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

Reply via email to