/azp run runtime-libraries-coreclr outerloop

/azp run runtime-libraries-coreclr outerloop

This PR is probably introducing some perf regression (here is one when using HttpClient in a proxy)

I think we should build a dedicated web app made for tracking telemetry/metrics performance (open to suggestions). It's a very important domain and its performance can be really impactful on apps. That would allow us to estimate the cost of changes, and detect regressions in related domains. We could also run this app retroactively and see if past changes have introduced changes we may have missed.

Could this be enabling all metrics in a process that was otherwise subscribed to none?

This part of the change was fixing a regression occurred by other changes. When you have empty specs, it means you need to subscribe to all metrics in the process. This was the .NET 8.0 behavior. Recently, we have added the System.Runtime meter reporting metrics for different runtime areas GC, jit,....etc.

@sebastienros how is the perf test written for the regressed part? does it listen to all meters? or just listen to the concerned meter? I expect some minor hits with the Gauge instrument as we started to synchronize the collected values but shouldn't be that much.

CC @noahfalk

does it listen to all meters?

There could be an issue in Crank then. I will review all the arguments we pass for this specific app (it doesn't show up in other ones) and how meters are recorded.