-
Notifications
You must be signed in to change notification settings - Fork 29
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
Can Clock provide delta_as_nanos
?
#84
Comments
I'm not sure I follow how you're using If you're already taking raw measurements ( You only pay the conversion cost once, the same as if you called |
Sorry for being unclear here - the conversion you describe is exactly what I'm doing. There are no const optimizations though, right? We're dealing with dynamic values, so the Anyway, to make this more concrete, I made a microbenchmark to measure the time spent doing each of these and the round-trip costs about 818 picoseconds on an M1max machine, almost a whole nanosecond (2.4ns on a Xeon Silver 4114 machine running Linux). This doesn't sound like a lot, but governor's rate-limiting operations take 20ns per, and so that conversion adds a pretty hefty chunk of overhead! |
Ah, sorry, right: I had forgotten that Short answer to the question as posed in the title: yes. Let's call it The move to exposing Might take a few days to whip this up -- time is sparse for me lately -- but I'm also open to a PR that works as described above. |
OK, that sounds like a good path forward! For |
I'd say, generally, I wouldn't be looking to introduce another type to |
Fair enough! That's an easy change, then (: |
This addresses metrics-rs#84 and should results in a benchmark that's 2ns faster (on a m1 max macOS machine) than the corresponding Duration-converting benchmark.
Closing as this has been long since taken care of. |
In governor, I am using a raw nanoseconds representation for quanta readings, which means that every time I take a clock reading, quanta converts nanos into an
std::time::Duration
from a nanos value, which I then convert back. That costs us quite a bit of performance, as well as being so dissatisfyingly close to what I want: You already have the right kind of value, can I just get it without costly conversions? (-:The text was updated successfully, but these errors were encountered: