Thanks! Is there any chance you could provide some sample code we could use to perform performance testing? Based on your description I have a suspicion that ScopedContext would perform even better but at this point that is just speculation without tests. Of course, that may be minimal and might not be worth the effort of having to change code.
You say that it is mostly for a logging/metrics library. Does that mean it is storing counters that it has to periodically increment? I’m curious there since the MDC/ThreadContextMap only support strings. Ralph > On May 24, 2024, at 12:00 PM, John Engebretson <jengebr...@gmail.com> wrote: > > Certainly! Our usage is widespread in our applications, and mostly > wrapped inside an internal logging/metrics library. Focusing on our most > performance-critical applications, our usage falls into two categories: > > 1. MDC sets/gets, ranging from 1 to 8 values at any given time. > 2. CloseableThreadContext, with attribute counts varying from 0 to 15 > values at any given time. > > Our performance profiling/investigation/tooling highlighted the cost of > HashMap operations when modifying the context; that cost involved cpu time, > critical-path clock time, and memory allocation/GC. The largest amount of > work comes from copying the old HashMap into the new one - iterating across > empty buckets, creating new Nodes, recalculating hashcodes, etc. > 2.24.0 will reduce the runtime cost with no application changes. We like > that outcome. :) > John > > On Fri, May 24, 2024 at 1:47 PM Ralph Goers <ralph.go...@dslextreme.com> > wrote: > >> >> >>> On May 24, 2024, at 11:10 AM, Piotr P. Karwasz <piotr.karw...@gmail.com> >> wrote: >>> >>> Hi John, >>> >>> On Fri, 24 May 2024 at 17:17, John Engebretson <jengebr...@gmail.com> >> wrote: >>>> As >>> I stated several times, 'ThreadContext.get()` is a mistake, because it >>> allows users to abuse the API and transport logging-unrelated data >>> through `ThreadContext`. If we could correct the past, I would remove >>> `ThreadContext.get()` and let `ThreadContext.put()` return the old >>> value. >> >> John, >> >> ThreadContextMap is obviously very important to your use case. Can you >> describe how you are using it? What about the way you are using it made you >> notice it was having an impact on performance? >> >> Ralph
