Bogdan Drutu

@felixge I am coming from usability perspective, these data are very hard to use by a backend or by any transformation service. Wearing my TC hat, I need to ensure...

>@bogdandrutu Are there any specific use cases you have in mind, where usability is being hurt by ProfilesData being a global dictionary? Any sort of transformation is almost impossible to...

>At this point in the implementation of profiling, and based on the fact that we are working around the complexity of the dictionary, I would therefore not go back on...

> If you look at the arrow ecosystem and algorithms designed to leverage simd instructions better, sparse vectors and index access may actually lend to more efficient (in flight) transformation....

But the "Logs API" is not a proper logging API, and recommending using it in lots of places (2-4) will actually suffer for more performance hit (by not having levels,...

@pellared also, just reading the introduction https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/README.md#introduction I read that we are not exposing a "final user" API, but we integrate with other APIs.

I think this is not about "allowing", it is about is it expected to have this instrumentation? Do we want to maintain this in all the language? etc. /cc @yurishkuro

@omzmarlon first thing first, please change to use readers. See https://github.com/open-telemetry/opentelemetry-collector/releases/tag/v0.111.0 deprecation notice.

The issue is done, any other blocker? Please update the issue for everyone to see the current status.

@felixge these days zstd is more of a standard than the gzip, can you try that as well?