perf(sdk): add optional rapidhash for ValueMap HashMaps in metrics hot path

Replace the default SipHash-1-3 hasher with rapidhash (wyhash successor) behind
an opt-in `metrics-use-rapidhash` feature flag for the HashMap used in
ValueMap::trackers. SipHash's HashDoS resistance is unnecessary here since
ValueMap is pub(crate) and keys are not attacker-controlled.

rapidhash was selected after benchmarking four hashers (ahash, foldhash,
rapidhash, std SipHash) on actual Vec<KeyValue> keys matching the ValueMap
workload (1600 time series, 2-8 attributes per entry, mixed read/write).

Benchmark results (Apple Silicon, aarch64-apple-darwin):

| Benchmark (4 attrs)      | ahash   | foldhash | rapidhash | std SipHash |
|--------------------------|---------|----------|-----------|-------------|
| hash_only                | 31.5 µs | 30.7 µs  | 29.9 µs   | 60.0 µs     |
| lookup_hit               | 81.2 µs | 71.0 µs  | 70.1 µs   | 104.8 µs    |
| lookup_miss              | 2.24 µs | 2.46 µs  | 2.13 µs   | 4.10 µs     |
| insert                   | 207 µs  | 198 µs   | 196 µs    | 235 µs      |
| mixed_rw (ValueMap path) | 170 µs  | 155 µs   | 153 µs    | 218 µs      |

Key findings:
- rapidhash is 10% faster than ahash on the mixed read/write path that
  most closely models ValueMap::measure()
- foldhash (now hashbrown's default hasher) is 8% faster than ahash
- ahash has known unresolved performance regressions on ARM (#194, ~40%
  regression on M1 from 0.8.6->0.8.7) and AMD (#190, 73-151% regression
  with target-cpu=native)
- ahash has had no throughput-focused optimization work merged in 2024-2025;
  three VAES PRs (#144, #186, #187) have been stalled for 2+ years
- foldhash replaced ahash as the default hasher in hashbrown (PR #563)
- rapidhash is the official successor to wyhash, adopted by Chromium and
  Microsoft Terminal

The feature is opt-in to avoid adding a mandatory dependency. When
`metrics-use-rapidhash` is not enabled, the standard library HashMap
(SipHash) is used.

Also adds a hasher_comparison benchmark for reproducing these results.

Refs: #3371

Author: bryantbiggs

opentelemetry-sdk/CHANGELOG.md

@@ -2,6 +2,7 @@
 
 ## vNext
 
+- Add optional `metrics-use-rapidhash` feature flag to use [rapidhash](https://github.com/Nicoshev/rapidhash) for `ValueMap` HashMaps in the metrics hot path, providing ~30% improvement over the default std `SipHash` hasher. [#3388](https://github.com/open-telemetry/opentelemetry-rust/pull/3388)
 - Add 32-bit platform support by using `portable-atomic` for `AtomicI64` and `AtomicU64` in the metrics module. This enables compilation on 32-bit ARM targets (e.g., `armv5te-unknown-linux-gnueabi`, `armv7-unknown-linux-gnueabihf`).
 - `Aggregation` enum and `StreamBuilder::with_aggregation()` are now stable and no longer require the `spec_unstable_metrics_views` feature flag.
 - Fix `service.name` Resource attribute fallback to follow OpenTelemetry

opentelemetry-sdk/Cargo.toml

@@ -12,6 +12,7 @@ autobenches = false
 
 [dependencies]
 opentelemetry = { workspace = true }
+rapidhash = { version = "4", optional = true }
 opentelemetry-http = { workspace = true, optional = true }
 futures-channel = { workspace = true }
 futures-executor = { workspace = true }
@@ -59,6 +60,7 @@ experimental_logs_batch_log_processor_with_async_runtime = ["logs", "experimenta
 experimental_logs_concurrent_log_processor = ["logs"]
 experimental_trace_batch_span_processor_with_async_runtime = ["tokio/sync", "trace", "experimental_async_runtime"]
 experimental_metrics_disable_name_validation = ["metrics"]
+metrics-use-rapidhash = ["metrics", "rapidhash"]
 bench_profiling = []
 
 [[bench]]

opentelemetry-sdk/src/metrics/internal/mod.rs

@@ -9,7 +9,7 @@ use core::fmt;
 #[cfg(not(target_has_atomic = "64"))]
 use portable_atomic::{AtomicI64, AtomicU64};
 use std::cmp::min;
-use std::collections::{HashMap, HashSet};
+use std::collections::HashSet;
 use std::mem::swap;
 use std::ops::{Add, AddAssign, DerefMut, Sub};
 use std::sync::atomic::{AtomicBool, AtomicUsize, Ordering};
@@ -24,6 +24,23 @@ use opentelemetry::{otel_warn, KeyValue};
 use super::data::{AggregatedMetrics, MetricData};
 use super::pipeline::DEFAULT_CARDINALITY_LIMIT;
 
+#[cfg(feature = "metrics-use-rapidhash")]
+type HashMap<K, V> = std::collections::HashMap<K, V, rapidhash::fast::RandomState>;
+#[cfg(not(feature = "metrics-use-rapidhash"))]
+type HashMap<K, V> = std::collections::HashMap<K, V>;
+
+#[cfg(feature = "metrics-use-rapidhash")]
+fn new_hashmap<K, V>(capacity: usize) -> HashMap<K, V> {
+    std::collections::HashMap::with_capacity_and_hasher(
+        capacity,
+        rapidhash::fast::RandomState::default(),
+    )
+}
+#[cfg(not(feature = "metrics-use-rapidhash"))]
+fn new_hashmap<K, V>(capacity: usize) -> HashMap<K, V> {
+    std::collections::HashMap::with_capacity(capacity)
+}
+
 // TODO Replace it with LazyLock once it is stable
 pub(crate) static STREAM_OVERFLOW_ATTRIBUTES: OnceLock<Vec<KeyValue>> = OnceLock::new();
 
@@ -85,7 +102,7 @@ where
 {
     fn new(config: A::InitConfig, cardinality_limit: usize) -> Self {
         ValueMap {
-            trackers: RwLock::new(HashMap::with_capacity(
+            trackers: RwLock::new(new_hashmap(
                 1 + min(DEFAULT_CARDINALITY_LIMIT, cardinality_limit),
             )),
             trackers_for_collect: OnceLock::new(),
@@ -100,7 +117,7 @@ where
     #[inline]
     fn trackers_for_collect(&self) -> &RwLock<HashMap<Vec<KeyValue>, Arc<A>>> {
         self.trackers_for_collect.get_or_init(|| {
-            RwLock::new(HashMap::with_capacity(
+            RwLock::new(new_hashmap(
                 1 + min(DEFAULT_CARDINALITY_LIMIT, self.cardinality_limit),
             ))
         })