Fix performance regression in MeterRegistry#remove

[shakuzen]

Adds a reverse look-up for the pre-filter meter ID for use when removing a Meter. This avoids the need to iterate over the meters in the cache (preFilterIdMeterMap), which scales linearly with the number of meters, and is problematic because it does this while holding the meterMap lock needed to add new meters. Also adds benchmarks for measuring the performance of the remove method with different numbers of meters registered.

Resolves #5466

[shakuzen]

Benchmark results demonstrating the issue:

Micrometer 1.14.2:

Benchmark                     (meterCount)  Mode  Cnt     Score    Error  Units
MeterRemovalBenchmark.remove         10000    ss  500   148.356 ± 12.588  us/op
MeterRemovalBenchmark.remove        100000    ss  500  4083.552 ± 89.167  us/op

With the changes in this pull request:

Benchmark                     (meterCount)  Mode  Cnt  Score   Error  Units
MeterRemovalBenchmark.remove         10000    ss  500  7.643 ± 1.256  us/op
MeterRemovalBenchmark.remove        100000    ss  500  2.519 ± 0.257  us/op

(I don't know why it's relatively slower with less meters)

[ikhoon]

Thanks for the quick fix. 👍👍

[jonatan-ivanov]

Should we add a line that unlike Sample this measures this calls the method once and also measures the "cold" performance?

[shakuzen]

It's not necessarily the cold performance we care about, but by the mutable nature of a remove method, we want to measure the performance of removing a meter that exists in the registry when the registry has a certain number of total meters, and I didn't know a good way to do that other than single shot mode. In other modes, we would either be measuring removing a meter from a registry with progressively less meters in total, or we would be measuring the time to remove a non-existent meter, which isn't what we want. I've added reasoning in a JavaDoc comment now.

[jonatan-ivanov]

I guess since we "only" doubling the references and not the objects, the memory impact is not too bad.

[shakuzen]

I guess since we "only" doubling the references and not the objects, the memory impact is not too bad.

That is my expectation, but we don't track/test this now. If anyone has good ideas on doing that, please share.