[logback-dev] [JIRA] Commented: (LBCLASSIC-254) Performance improvement for LogbackMDCAdapter

[Michael Franz (JIRA)]

    [ http://jira.qos.ch/browse/LBCLASSIC-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11973#action_11973 ] 

Michael Franz commented on LBCLASSIC-254:
-----------------------------------------

Hello Ceki, 

I've looked over the whole application code and actually there is only one very rarely called get-operation on the MDC. So your approach would also work in my scenario. 

But as a software developer I would feel a bit uncomfortable with your strategy: "copy on write after read" sounds quite uncommon against "copy on write" and "lazy copy". With your approach you are forcing developers to keep an eye on the order of put- and get-operations, especially if an application performs existence checks before writing on the MDC. As long as only puts are performed (like in my case) your approach is sufficient. I don't know if there are real world applications that often call gets. Nevertheless this is just a feeling.

> 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