Add benchmark for map access using attribute Equivalent

[dashpole]

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: https://github.com/prometheus/common/blob/c79a891c6c28ce135a2ac082b721c2dacc2269a8/model/signature.go#L31

[MrAlias]

• compute a uint64 hash using something like https://github.com/gohugoio/hashstructure, or something similar to what prometheus/client_golang does: https://github.com/prometheus/common/blob/c79a891c6c28ce135a2ac082b721c2dacc2269a8/model/signature.go#L31

@dashpole see #5028

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.9%. Comparing base (49033aa) to head (3ebd0f3).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #7123   +/-   ##
=====================================
  Coverage   82.9%   82.9%           
=====================================
  Files        262     262           
  Lines      24461   24461           
=====================================
+ Hits       20291   20294    +3     
+ Misses      3794    3791    -3     
  Partials     376     376           

see 2 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.