[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17792222#comment-17792222
]
Matt Sicker commented on LOG4J2-2795:
-------------------------------------
This likely depends on [https://github.com/apache/logging-log4j2/issues/1344]
(moving JMX stuff to its own module) and
[https://github.com/apache/logging-log4j2/issues/1977] (remove support for
specifying classes via strings like system properties). To better support Java
modules and GraalVM, I might end up enhancing the plugin processor to generate
more metadata at compile time not only to make sure I _have_ that data in the
first place, but it should also help reduce startup time, too, as reflection
will be involved far less.
> Make LogManager/LoggerContext creation time reasonable
> ------------------------------------------------------
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
> Affects Versions: 2.13.0
> Reporter: Romain Manni-Bucau
> Priority: Major
> Attachments: image-2020-03-06-08-58-21-169.png, log4j2.png
>
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
