Currently, we track the supplied cardinality in a metric (extracted via the dd.internal.card tag) by holding on to the raw string value in MetricMetadata. At the present size of 104 bytes, the cardinality field alone represents roughly ~25% of the size of MetricMetadata. Even with #187 merged, this will only go down to a total size of 80 bytes with no other changes, and cardinality will still represent ~20% of the overall struct size.
We originally did this because it let us punt on having a separate cardinality enum, since the only current cardinality enum is defined in saluki-env, and since we might want to keep the raw value in order to avoid being specifically coupled to the cardinality values used by the Datadog Agent.
However, since we'd have to do a code update to update the variants of the enum in saluki-env anyways, it seems like we should just do the enum-based approach in saluki-event and handle the enum-to-enum mapping in the relevant spots. It seems like it's worth the memory savings.
Context
Currently, we track the supplied cardinality in a metric (extracted via the
dd.internal.cardtag) by holding on to the raw string value inMetricMetadata. At the present size of 104 bytes, thecardinalityfield alone represents roughly ~25% of the size ofMetricMetadata. Even with #187 merged, this will only go down to a total size of 80 bytes with no other changes, andcardinalitywill still represent ~20% of the overall struct size.We originally did this because it let us punt on having a separate cardinality enum, since the only current cardinality enum is defined in
saluki-env, and since we might want to keep the raw value in order to avoid being specifically coupled to the cardinality values used by the Datadog Agent.However, since we'd have to do a code update to update the variants of the enum in
saluki-envanyways, it seems like we should just do the enum-based approach insaluki-eventand handle the enum-to-enum mapping in the relevant spots. It seems like it's worth the memory savings.