[
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
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
