Recorder implementations that don't use maps for metric storage

[david-perez]

All Recorder implementations I've seen ultimately use maps keyed by metric Key for storage. This makes sense, as the trait's methods take in arbitrary Keys; it can't foresee all the metrics that are going to be emitted.

However, this penalizes applications that know ahead of time all the metrics they are going to emit. At work we've profiled some high-performance applications where ~10% of CPU time is spent in hashmap/ entry manipulations.

I was wondering how to efficiently leverage metrics.rs and the Recorder API for use cases where applications store metrics for a unit of work in static data structures like e.g. a struct.

[tobz]

Simplest approach I can think of would be to match the key name and emit the appropriate static counter/gauge/etc.

Dealers choice on whether it's a static match with a fixed number of patterns or if you use something more exotic like a trie, etc... but that might be the best you could hope for with the Recorder API.