Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explore migrating Recency to use timestamps directly. #279

Open
tobz opened this issue Mar 1, 2022 · 0 comments
Open

Explore migrating Recency to use timestamps directly. #279

tobz opened this issue Mar 1, 2022 · 0 comments
Labels
C-util Component: utility classes and helpers. E-complex Effort: complex. T-enhancement Type: enhancement. T-experiment Type: experiment.

Comments

@tobz
Copy link
Member

tobz commented Mar 1, 2022

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.

@tobz tobz added C-util Component: utility classes and helpers. E-complex Effort: complex. T-enhancement Type: enhancement. T-experiment Type: experiment. labels Mar 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-util Component: utility classes and helpers. E-complex Effort: complex. T-enhancement Type: enhancement. T-experiment Type: experiment.
Projects
None yet
Development

No branches or pull requests

1 participant