[
https://issues.apache.org/jira/browse/LOG4J2-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006167#comment-17006167
]
Carter Kozak commented on LOG4J2-2750:
--------------------------------------
I took a bit of time to refactor the FileAPpenderThrowableBenchmark to better
support all tests across logger implementations (I'll commit the cleaned up
benchmarks separately)
{noformat}
Benchmark
(loggingConfiguration) Mode Cnt Score Error Units
FileAppenderThrowableBenchmark.complexThrowable
LOG4J2_EXTENDED_THROWABLE thrpt 3 12548.240 ± 4537.982 ops/s
FileAppenderThrowableBenchmark.complexThrowable
LOG4J2_EXTENDED_THROWABLE_ASYNC thrpt 3 23471.129 ± 1719.544 ops/s
FileAppenderThrowableBenchmark.complexThrowable
LOG4J2_THROWABLE thrpt 3 19934.228 ± 3873.089 ops/s
FileAppenderThrowableBenchmark.complexThrowable
LOG4J2_THROWABLE_ASYNC thrpt 3 18895.930 ± 1580.131 ops/s
FileAppenderThrowableBenchmark.complexThrowable
LOG4J1 thrpt 3 14897.978 ± 1208.692 ops/s
FileAppenderThrowableBenchmark.complexThrowable
LOGBACK thrpt 3 26345.056 ± 1624.110 ops/s
FileAppenderThrowableBenchmark.complexThrowable
JUL thrpt 3 12861.171 ± 878.020 ops/s
FileAppenderThrowableBenchmark.simpleThrowable
LOG4J2_EXTENDED_THROWABLE thrpt 3 100451.952 ± 3765.250 ops/s
FileAppenderThrowableBenchmark.simpleThrowable
LOG4J2_EXTENDED_THROWABLE_ASYNC thrpt 3 162728.808 ± 1420.393 ops/s
FileAppenderThrowableBenchmark.simpleThrowable
LOG4J2_THROWABLE thrpt 3 202087.738 ± 10322.562 ops/s
FileAppenderThrowableBenchmark.simpleThrowable
LOG4J2_THROWABLE_ASYNC thrpt 3 157930.496 ± 4736.728 ops/s
FileAppenderThrowableBenchmark.simpleThrowable
LOG4J1 thrpt 3 135099.479 ± 4284.465 ops/s
FileAppenderThrowableBenchmark.simpleThrowable
LOGBACK thrpt 3 252810.483 ± 38815.259 ops/s
FileAppenderThrowableBenchmark.simpleThrowable
JUL thrpt 3 94715.581 ± 2076.642 ops/s
{noformat}
Things get exciting when I flip the property to disable ThrowableProxy class
loading (I left non-extended throwables enabled here as a baseline for direct
comparison with the values above):
{noformat}
Benchmark (loggingConfiguration)
Mode Cnt Score Error Units
FileAppenderThrowableBenchmark.complexThrowable LOG4J2_EXTENDED_THROWABLE
thrpt 3 33171.757 ± 4163.779 ops/s
FileAppenderThrowableBenchmark.complexThrowable LOG4J2_THROWABLE
thrpt 3 20173.641 ± 1920.702 ops/s
FileAppenderThrowableBenchmark.simpleThrowable LOG4J2_EXTENDED_THROWABLE
thrpt 3 312647.865 ± 15948.289 ops/s
FileAppenderThrowableBenchmark.simpleThrowable LOG4J2_THROWABLE
thrpt 3 200264.627 ± 3843.117 ops/s
{noformat}
Benchmarks run on openjdk13.0.1+9.
With this flag set, the ExtendedThrowablePatternConverter far exceeds
performance of the standard ThrowablePatternConverter as well as logback. I
imagine this has something to do with Throwable.printStackTrace -> PrintWriter
-> StringBuilderWriter inefficiency, and internal Throwable.printStackTrace
using a PrintStreamOrWriter shim which only supports println requiring heavy
string concatenation.
I think these results suggest that this is worth figuring out a solution. I
don't have a strong preference toward the system property if something else
will work similarly well.
> Setting to disable extended stack trace for layouts
> ---------------------------------------------------
>
> Key: LOG4J2-2750
> URL: https://issues.apache.org/jira/browse/LOG4J2-2750
> Project: Log4j 2
> Issue Type: Improvement
> Components: Layouts
> Reporter: Mikhail Talisov
> Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> By default almost all layouts use an extended stack trace output format
> (ExtendedStackTraceElement). Currently I can change the stack trace format in
> PatternLayout by specifiyng its template (%throwable, %xThrowable, etc). When
> specified %throwable then no class packaging information is included in
> output.
> But when I use for example JsonLayout or AsyncAppender with any layout then
> no way to exclude class packaging information from the stack trace (this mean
> class loading from classpath for all stack trace elements). For performance
> reason would be good to have a setting to disable extending the stack trace
> in layouts.
> It's possible to add new attribute "extendedStackTrace" (for example, which
> is true by default) in layout elements (except PatternLayout and some other
> layouts where no ThrowableProxyHelper#toExtendedStackTrace is using). When I
> set extendedStackTrace="false" then stack trace must be serialized without
> class loading for all stack trace elements. AsyncAppender must use refs
> appender layout's attribute.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
