mirror of
https://github.com/netbirdio/gvisor.git
synced 2026-05-22 17:12:49 -07:00
Etienne Perot
79b38029d7
This optimizes both increments and lookup operations. It does so using the following: - For metrics of potential cardinality larger than 48, it will switch to using a map rather than linear search for mapping field value combinations to the index that combination corresponds to in the flattened list of values. For metrics of cardinality 48 or smaller, linear search is still used as it is still faster (and also still faster than binary search), as determined by benchmarks. - All field values are checked for pointer uniqueness (i.e. the pointer to the start of each field value string must be unique). This is then used for faster matching: instead of comparing whole strings (and needing to hash them, in the case of doing map-based lookups), it compares pointer values. In the context of this metric library, because all field values must be pre-declared ahead of time, keeping references to these pre-declared strings should always be possible. This is enforced: it will `panic` if the metric user does not do this. In practice, this is easy to do by using `const` strings for all metric values. This change does just that for existing metrics with string fields. From benchmarks, this speeds up the time to take a snapshot of existing metrics by -8.35%. With the unimplemented syscall counter metric, this optimization reduces the slowdown of adding this metric from +4,250% to a still-large but much more manageable +290%. A further optimization (cl/524419591) will reduce this overhead further before re-introducing the unimplemented syscall counter metric. PiperOrigin-RevId: 526134756