Hi Stephan, On Thu, 25 May 2023 at 21:35, Stephan Markwalder <step...@markwalder.net> wrote: > 2. As of today, the cached formatted time is only reused if an event is > logged with the exact same `epochSecond` and `nanoOfSeconds` as the cached > time. But if the DatePatternConverter is configured with a time pattern > like "HH:mm:ss" which ignores everything more accurate than seconds, then > the value of `nanoOfSeconds` is actually irrelevant. No matter what this > value is, the formatted time will only be different if the value of > `epochSecond` is different. In other words, the same cached formatted time > could be reused as long as `instant.getEpochSecond() == > cached.epochSecond`. All events logged within the same second could benefit > from the cached formatted time. With some more logic, a similar improvement > could be achieved when using the default time pattern "HH:mm:ss,SSS", only > that the code now would have to compare the values of `nanoOfSeconds / > 1000000`.
I totally agree with your remark and I have implemented it in: https://github.com/apache/logging-log4j2/pull/1491 Another problem with the DatePatternConverter IMHO is the usage of `AtomicReference` to sync the cached value between threads. I think this is the other reason for the 2.5 µs difference between formatting timestamps using thread locals and without them. Experimentally using a simple non-volatile class field for the cache works better: the fact that multiple threads see a different cached value is actually an advantage here. Also apparently the cost of syncing the cached value among threads is not compensated by a smaller number of cache misses. Piotr
