[logback-dev] [JIRA] Commented: (LBCLASSIC-254) Performance improvement for LogbackMDCAdapter
Ceki Gulcu (JIRA)
noreply-jira at qos.ch
Fri Mar 4 21:27:51 CET 2011
[ http://jira.qos.ch/browse/LBCLASSIC-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11971#action_11971 ]
Ceki Gulcu commented on LBCLASSIC-254:
--------------------------------------
Hi Michael,
After looking at your code, I got an idea and was wondering if it would meet your needs.
Instead of keeping two maps, we keep a single map but copy it only if necessary. All we need for efficient/timely copying is a variable keeping track of the last operation. A copy is necessary on 'put' or 'remove' but only if the last operation was a 'get'.Get operations never necessitate a copy nor successive 'put/remove' operations, only a get followed by a 'put/remove' requires copying the map.
With that in mind, let (m, 'op') designate the tuple consisting of hashMap 'm' and last operation 'op'. So, for example, "put: (m1, 'get') -> (m2, 'put')" states that in response to a put operation the map m1 is transformed into a new map m2. The lastOperation variable is changed from 'get' to 'put'.
Here is an illustration of changes into the MDC structure with this notation:
put: (null, null) -> (m0, 'put')
put: (m0, 'put') -> (m0, 'put)
get: (m0, 'get') -> (m0, 'get')
get: (m0, 'get') -> (m0, 'get')
remove: (m0, 'get') -> (m1, 'remove')
get: (m1, 'remove') -> (m1, 'get')
get: (m1, 'get') -> (m1, 'get')
remove: (m1, 'get') -> (m2, 'remove')
... and so on
Note that 8 operations were performed by only 3 maps were created.
What do you think?
> 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
> 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
More information about the logback-dev
mailing list