[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17515448#comment-17515448
]
Matt Sicker commented on LOG4J2-2795:
-------------------------------------
Collecting plugins only loads the metadata for each plugin, not the plugin
class itself. The class isn't loaded until we need to first create a plugin of
that type. Basically, the configuration nodes are matched to PluginType
instances which contain the metadata and a way to load the corresponding plugin
class. Only when a plugin is referenced in a configuration do we attempt to
load its corresponding plugin class and then construct it.
As for the cache file decoding, that's for backward compatibility with 2.x. We
don't generate any plugin cache file anymore, so that shouldn't be adding any
time except for looking to see if a resource exists in the ClassLoader.
Basically, it might help to do some profiling here to find what's really taking
so much time.
> 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)
