roslyn
roslyn copied to clipboard
dotnet
Try to reduce JIT costs for AbstractLogAggregator
We're seeing some heavier JIT costs for derived types of AbstractLogAggregator because we often instantiate the types with a TKey that is a value type; the CLR always has to JIT separate native code for each value type being used since the code can't be shared. Since the JIT cost is providing to be larger than we'd like, this changes the underlying dictionary to be a ConcurrentDictionary where both generic parameters are strongly typed as reference types, which the JIT is able to reuse. TKey is changed to an object (where we will now pay boxing costs), and TValue is simply constrained to be a class since in practice it always was.
Fixes AB#1580049
Since the JIT cost is providing to be larger than we'd like,
What sort of cost are we talking about here?
What sort of cost are we talking about here?
The problem isn't jitting, ngen with IBC data actually have all instances pre-compiled just fine. The problem is the additional page-faults (possibly because having separate pre-compiled code for each instance?) causes delay in Close VS scenario for slow disks, from 2100ms to 2700ms (25% regression)
My hunch is that number is actually much larger than it should be since even if we have multiple copies of code there shouldn't be that much code. If we were on .NET Core I'd ask the runtime folks to take a look. On .NET Framework though there's not much we can do here.
My hunch is that number is actually much larger than it should be since even if we have multiple copies of code there shouldn't be that much code.
Larger than the size of additional code? probably. But we don't know how much impact the code layout change has to page faults counts. Maybe ngen is doing a poor job and all those instances are scattered in ngen'd image and we ended up loading lots of unnecessary code just because they reside in the same pages?
If the boxing is the only concern, maybe have a "box pool" shared by all LogAggregators? TBH it's hard to image this being a big issue but this would be a simple solution for it
I'm not sure I care about an upfront 600ms. That's two eye blinks. It feels fine to take that one time hit versus constant extra gc pressure.
Also unsure about what we mean by slow disks. Doesn't vs require ssds at this point?