[ http://jira.qos.ch/browse/LBCLASSIC-254?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu resolved LBCLASSIC-254. ---------------------------------- Fix Version/s: 0.9.29 Resolution: Fixed I just committed a patch [1] which fixes this performance issue as well as another yet unreported bug. [1] http://github.com/ceki/logback/commit/e068bd3b9754e8d6
Performance improvement for LogbackMDCAdapter ---------------------------------------------
Key: LBCLASSIC-254 URL: http://jira.qos.ch/browse/LBCLASSIC-254 Project: logback-classic Issue Type: Improvement Components: Other Affects Versions: 0.9.28 Reporter: Michael Franz Assignee: Ceki Gulcu Fix For: 0.9.29
Attachments: LogbackMDCAdapter.java
During performance analysis of our application the LogbackMDCAdapter showed up as a performance hotspot. This is because the application does relatively often replaces multiple entries in the MDC at ones, e.g. 6 removes/writes without any intermediate log statement. Also actual log messages that come through filtering before creating the LoggingEvent are relatively rare in production environments. I have reworked the implementation to improve the performance. The main idea is to defer cloning the internal Map as long possible. This patch increased overall application performance by about 10% in that test. Other application types were MDC changes are small and many LoggingEvent objects are created (calls to getPropertyMap()) should not be affected significantly. Note: I haven't check if my patch would reintroduce the #LBCLASSIC-183, but my subclasses of InheritableThreadLocal does not override the initialValue() method, so it could work.
-- 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