It struck me that it may be possible to utilize timestamps directly in the metric primitives for Recency instead of needing to track a generation counter and then also store the last seen times for metrics.
Pros:
no need to track all in-flight metrics; they would track themselves, essentially
logic becomes vastly simpler
no change in memory size/layout since we can represent a timestamp, in nanoseconds, using u64
Cons:
measuring current time can often be very slow
dealing with overflow logic (time should be monotonic, but sometimes libraries find this hard to guarantee)
Using quanta could be an answer to the "measuring current time might be slow" bit, doubly so using the "recent time" feature... but it could conflict with applications that used that feature for their own purposes. If their updates were too coarse, or got stopped for some reason, recency tracking could break.
While querying the current time might take 10-15ns in the very best case, incrementing an atomic counter can be close to half of that. Additionally, we would still need to atomically store the time which means we would be both querying the time and atomically storing it. The concept itself is not entirely unworkable given that it has tangible improvements to the clarity of the code, but we might need a more sophisticated approach to reduce the overhead.
It struck me that it may be possible to utilize timestamps directly in the metric primitives for
Recencyinstead of needing to track a generation counter and then also store the last seen times for metrics.Pros:
u64Cons:
Using
quantacould be an answer to the "measuring current time might be slow" bit, doubly so using the "recent time" feature... but it could conflict with applications that used that feature for their own purposes. If their updates were too coarse, or got stopped for some reason, recency tracking could break.While querying the current time might take 10-15ns in the very best case, incrementing an atomic counter can be close to half of that. Additionally, we would still need to atomically store the time which means we would be both querying the time and atomically storing it. The concept itself is not entirely unworkable given that it has tangible improvements to the clarity of the code, but we might need a more sophisticated approach to reduce the overhead.