Josh Suereth

We (Google) would be a fan of this change, giving us freedom to control performance going forward with differing implementations

@jkwatson One thing I want to mention is that I think the legacy use case here (adapting JMX -> OTel), should that be something the API supports or not? Specifically:...

@yangtaoran The prometheus exporter is not fully specified in OTEL yet. I fully expect resource -> prometheus labels to part of that final specification, but we're still discussing the details...

A few things I found when benchmarking and investigating the initial prototype: - `MapCounter` uses both `ConcurrentMap` and `AtomicLong`. However, the current `Handle` puts both of these behind a strict...

Here's a quick comparison of using a Circular-Buffer (with preallocated array of integers) vs. MapCounter: https://github.com/open-telemetry/opentelemetry-java/compare/main...jsuereth:wip-exponential-counter-perf It's a 2x performance differential. I think (in practice) the # of measurements per-histogram...

`320*8*2` = 5120 byes per histogram metric stream vs. `320*1*2` = 640 bytes. It's a big memory differential for histograms.... But yeah I sw the comments and understand the current...

> @jsuereth Found this issue - can you clarify whether unbind is really necessary? Sorry I missed this. 1. Unbind will be necessary (at a minimum) at the SDK level....

> Also is unbind necessary? Or is it ok to just let the bound counter get garbage-collected? I'm not sure so to confirm, is it possible to call > >...

First fix: #3835, up-to 87%-ish

> Every permutation of tags is a separate instrument. As of today Micrometer has no concept of exemplars. Baggage != exemplars. baggage is the ability to attach labels (dynamically) via...