[ https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17053143#comment-17053143 ]
Romain Manni-Bucau commented on LOG4J2-2795: -------------------------------------------- Hi [~rgoers], I have a few questions about some code parts and in particular org.apache.logging.log4j.core.config.AbstractConfiguration#initialize and friends: # why a ScriptManager is created there? can't it be created lazily in org.apache.logging.log4j.core.config.AbstractConfiguration#doConfigure, it triggers some serious loading for nothing most of the time # why PluginManager isnt cached per package? # why we can't get a static extension support in configuration factory (@ConfigurationFactoryConfiguration(suffixes = \{".xml"})) to avoid to load the class and instantiate it if not needed, the processor would store it avoid a bunch of classloading for nothing # Same in org.apache.logging.log4j.core.lookup.Interpolator#Interpolator(org.apache.logging.log4j.core.lookup.StrLookup, java.util.List<java.lang.String>), why eveything is early instantiated? Will not solve everything but at least the ScriptManager drop helps for me. > 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.3.4#803005)