[
http://jira.qos.ch/browse/LBCLASSIC-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12313#action_12313
]
Phil commented on LBCLASSIC-300:
--------------------------------
After implementing this fix (see diff attached to this report), performance
analysis shows that there was no significant speed increase.
See analysis sent to the dev mailing list...
http://mailman.qos.ch/pipermail/logback-dev/2011-November/006915.html
This is most likely caused by the fact that classloading and static
initialization dominates the initialization costs, and very few classes are
avoided being loaded with this fix.
My recommendation is for this issue to be closed without applying the diff.
> Add ability to manually specify configuration BEFORE autoconfiguration
> ----------------------------------------------------------------------
>
> Key: LBCLASSIC-300
> URL: http://jira.qos.ch/browse/LBCLASSIC-300
> Project: logback-classic
> Issue Type: Improvement
> Affects Versions: 0.9.29
> Reporter: Phil
> Assignee: Logback dev list
> Priority: Minor
> Attachments: 4_ContextInitializer.diff, CliTest.java, CliTest.txt
>
>
> In order to make logback initialization faster, I would like the ability to
> programmatically configure logback and avoid the logic that happens in
> ContextInitializer.autoConfig().
> Specifically, refer to this stack that occurs when getILoggerFactory() is
> initially called...
> ch.qos.logback.classic.util.ContextInitializer.autoConfig() line: 147
> org.slf4j.impl.StaticLoggerBinder.init() line: 85
> org.slf4j.impl.StaticLoggerBinder.<clinit>() line: 55
> org.slf4j.LoggerFactory.bind() line: 121
> org.slf4j.LoggerFactory.performInitialization() line: 111
> org.slf4j.LoggerFactory.getILoggerFactory() line: 268
> Now, for some background...
> I am using logback for a fast executing CLI program. Right now, initializing
> logback dominates the execution time of my CLIs. For example...
> When I started with logback, I was using logback.xml. If one of my CLIs took
> 1.5 seconds to run, I would see that initializing logback was taking 1 of
> those seconds (I used the yourkit profiler to identify this). 66% of the
> execution time is unacceptable.
> So, I switched from using logback.xml to programatically configuring logback
> in Java with the following code..
> {code}
> LoggerContext loggingContext = (LoggerContext)
> LoggerFactory.getILoggerFactory();
> loggingContext.reset();
> ...
> FileAppender<ILoggingEvent> fileAppender = new
> FileAppender<ILoggingEvent>();
> ...
> Logger rootLogger = loggingContext.getLogger(Logger.ROOT_LOGGER_NAME);
> rootLogger.addAppender(fileAppender);
> {code}
> This reduced the initialization time quite a bit. Now logback initialization
> is taking about .3 seconds. This is much better.
> However, I still think this can be improved by completely skipping the auto
> config logic.
> The initial call to LoggerFactory.getILoggerFactory() will attempt to auto
> configure logback.... which searches for groovy files, xml files, and falls
> back to BasicConfigurator. I don't need this auto configuration logic, since
> I am just going reset it and configure it myself anyway.
> I would like the ability to programmatically configure logback and totally
> avoid this auto configuration.
> Ideally I would be able to construct a LoggerContext instance, or the root
> Logger, or something. Then allow slf4j to bind to it without going through
> the auto config steps.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.qos.ch/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/logback-dev
