[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