You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This means that the metrics macros might potentially allocate at every call. Obviously this is not ideal.
A solution from metrics side would be for a Key to be constructible with a label without any allocation. So in the same sense that name is a ScopedString, the labels could something like: Cow<&'static, [&'static str]>. So for the special case where the labels are a slice of &'static str this would not allocate. I think this would be ideal.
The text was updated successfully, but these errors were encountered:
We've reworked how keys are handled in #87, but this is still covered, ultimately, by the caching mechanism introduced in #80, so I'm going to close this.
Currently creating a key from labels will allocate a vector every time, even if the labels are
&'static str
.metrics/metrics-core/src/lib.rs
Line 98 in 2f3e344
metrics/metrics-core/src/lib.rs
Line 211 in 2f3e344
This means that the metrics macros might potentially allocate at every call. Obviously this is not ideal.
A solution from metrics side would be for a
Key
to be constructible with a label without any allocation. So in the same sense thatname
is aScopedString
, the labels could something like:Cow<&'static, [&'static str]>
. So for the special case where the labels are a slice of&'static str
this would not allocate. I think this would be ideal.The text was updated successfully, but these errors were encountered: