[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515011#comment-17515011
]
Matt Sicker commented on LOG4J2-2795:
-------------------------------------
{quote}Wonder if you evaluated to not collect plugins but just try to load them
lazily when they are referenced. Concretely, ConsoleAppender wouldnt be loaded
until it appears in some configuration etc...Also loading it using a registrar
class (kind of ServiceLoader mecanism but with a name deduced from the name
encoutered by log4j) can enable to simplify the serialization too and get back
to something closer to the previous (v1) configuration where it was loaded per
class directly (even if it still has an indirection with the resource lookup
but it is a bit better).
{quote}
This is exactly how it works in master right now.
The static init stuff is something I'll have to look into. It's possible that
the remaining lag is from things in log4j-api that could be refactored.
> 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)
