I am looking into I am looking into
https://promlabs.com/blog/2025/07/17/why-i-recommend-native-prometheus-instrumentation-over-opentelemetry/#comparing-counter-increment-performance,
and was trying to figure out why incrementing a counter with 10
attributes was so much slower than incrementing a counter with no
attributes, or 1 attribute:
```
$ go test -run=xxxxxMatchNothingxxxxx -cpu=1 -test.benchtime=1s -bench=BenchmarkSyncMeasure/NoView/Int64Counter/Attributes
goos: linux
goarch: amd64
pkg: go.opentelemetry.io/otel/sdk/metric
cpu: Intel(R) Xeon(R) CPU @ 2.20GHz
BenchmarkSyncMeasure/NoView/Int64Counter/Attributes/0 9905773 121.3 ns/op
BenchmarkSyncMeasure/NoView/Int64Counter/Attributes/1 4079145 296.5 ns/op
BenchmarkSyncMeasure/NoView/Int64Counter/Attributes/10 781627 1531 ns/op
```
Looking at the profile, most of the time is spent in
"runtime.mapKeyError2" within "runtime.mapaccess2". My best guess is
that whatever we are using for Equivalent() is not very performant when
used as a map key. This seems like a good opportunity to greatly improve
the performance of our metrics (and probably other signals) API + SDK.
To start, i'm adding a simple benchmark within the attribute package to
isolate the issue. Results:
```
$ go test -run '^$' -bench '^BenchmarkEquivalentMapAccess' -benchtime .1s -cpu 1 -benchmem
goos: linux
goarch: amd64
pkg: go.opentelemetry.io/otel/attribute
cpu: Intel(R) Xeon(R) CPU @ 2.20GHz
BenchmarkEquivalentMapAccess/Empty 2220508 53.58 ns/op 0 B/op 0 allocs/op
BenchmarkEquivalentMapAccess/1_string_attribute 622770 196.7 ns/op 0 B/op 0 allocs/op
BenchmarkEquivalentMapAccess/10_string_attributes 77462 1558 ns/op 0 B/op 0 allocs/op
BenchmarkEquivalentMapAccess/1_int_attribute 602163 197.7 ns/op 0 B/op 0 allocs/op
BenchmarkEquivalentMapAccess/10_int_attributes 76603 1569 ns/op 0 B/op 0 allocs/op
```
This shows that it is the map lookup and storage itself that is making
the metrics API+SDK perform much worse with more attributes.
Some optimization ideas include:
* Most attribute sets are likely to be just numbers and strings. Can we
make a fast path for sets that don't include complex attributes?
* We encourage improving performance of the metrics API by re-using
attribute sets where possible. If we can lazily compute+cache a "faster"
map key, that will have a big performance improvement when attribute
sets are re-used.
* compute a uint64 hash using something like
https://github.com/gohugoio/hashstructure, or something similar to what
prometheus/client_golang does:
c79a891c6c/model/signature.go (L31)
---------
Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
Co-authored-by: Flc゛ <four_leaf_clover@foxmail.com>
* Deprecate Array attribute in favor of *Slice types
* Use new attr types in Jaeger exporter
* Use slice attr types in otlpmetric
* Use slice attr types in otlptrace
* Use slice attr types in zipkin exporter
* Remove array attr test from deprectated oteltest func
* Use StringSlice for cmd arg resource attr
* Add changes to the changelog
* Remove use of deprecated Array func
Group benchmarks by type for easier understanding and filtering.
Save output of function calls in benchmarks to file level vars to ensure
the compiler does not optimize away the test.
Unify testing functionality for common benchmark tasks.
