[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17513069#comment-17513069
]
Matt Sicker commented on LOG4J2-2795:
-------------------------------------
Sweet, thanks. I'm still finishing up plugin inversion here that would enable
lazy loading of some unnecessary things (particularly StrLookup and
PatternConverter plugins) which should help to some extent. Another existing
configuration option you could try to compare startup time with would be
defining the system property {{log4j2.disable.jmx}} to {{{}true{}}}. This
should give a more reasonable measurement for what Log4j itself is doing as JMX
itself initializes quite a few classes. Once I can make StrLookup plugins lazy,
then the {{jvmrunargs}} lookup will stop causing some other JMX classes to be
loaded until that lookup is actually used.
> 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.1#820001)
