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
