[
https://issues.apache.org/jira/browse/LOG4J2-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006210#comment-17006210
]
Carter Kozak commented on LOG4J2-2391:
--------------------------------------
Taking a look at this again, I think there are some optimizations we can make
on the current implementation:
Given a lambda class (we can check if the class name contains $Lambda$) or a
dynamic proxy (.$Proxy substring) we can avoid class loading because these
classes are not loaded from jars, so extended information will not exist.
When classes cannot be loaded, we waterfall through four classloader.load
operations:
1. lastLoader.loadClass
> LoaderUtil.loadClass
2. getThreadContextClassLoader().loadClass
3. Class.forName
4. ThrowableProxyHelper.class.getClassLoader().loadClass
I imagine several of these use the same loader, so we should be able to
deduplicate down to a single class loader in the common case.
> Investigate ThrowableProxy performance
> --------------------------------------
>
> Key: LOG4J2-2391
> URL: https://issues.apache.org/jira/browse/LOG4J2-2391
> Project: Log4j 2
> Issue Type: Task
> Affects Versions: 2.11.1
> Reporter: Carter Kozak
> Assignee: Carter Kozak
> Priority: Major
>
> I've noticed when applications get into a state where they log more
> exceptions than usual (e.g. network connectivity issues) thread dumps contain
> many threads working inside of ThrowableProxy, loading classes.
> A simple jmh benchmark of a pattern layout writing to disk with a message and
> throwable appears to write about 160,000 events/second using a throwable, and
> 2,000 events/second using ThrowableProxy.
> I will investigate to understand where the substantial difference is coming
> from, and clean up the benchmarks to add to the log4j2 benchmarking module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
