27

At first I thought it can be used for performance measurements. But it is said that std::chrono::high_resolution_clock may be not steady (is_steady may be false). It is also said that std::chrono::high_resolution_clock may even be an alias of std::chrono::system_clock which is generally not steady. So I can't measure time intervals with this type of clock because at any moment the clock may be adjusted and my measurements will be wrong.

At the same time I can't convert time points of std::chrono::high_resolution_clock to calendar time because it doesn't have to_time_t method. So I can't get the real time with this type of clock either.

Then what can std::chrono::high_resolution_clock be used for?

T.C.
  • 133,968
  • 17
  • 288
  • 421
anton_rh
  • 8,226
  • 7
  • 45
  • 73
  • 2
    Well, since it may be an alias it cannot be steady, since `system_clock` is not steady, as you point out. It's an optional clock, that's it. If an implementation can't support it, you get the `system_clock` in its place. But, if you're in luck, you got yourself a spiffy, shiny, high resolution clock. – Sam Varshavchik May 25 '16 at 02:33
  • 1
    @Ken White: The first answers I get from your link have nothing to do with std::chrono::high_resolution_clock. – MikeMB May 25 '16 at 07:07
  • 1
    @KenWhite almost every result you linked to has nothing to do with the C++ class asked in this question – johnbakers May 25 '16 at 07:07

2 Answers2

40

There are none.

Sorry, my bad.

If you are tempted to use high_resolution_clock, choose steady_clock instead. On libc++ and VS high_resolution_clock is a type alias of steady_clock anyway.

On gcc high_resolution_clock is a type alias of system_clock and I've seen more than one use of high_resolution_clock::to_time_t on this platform (which is wrong).

Do use <chrono>. But there are parts of <chrono> that you should avoid.

  • Don't use high_resolution_clock.
  • Avoid uses of .count() and .time_since_epoch() unless there is no other way to get the job done.
  • Avoid duration_cast unless the code won't compile without it, and you desire truncation-towards-zero behavior.
  • Avoid explicit conversion syntax if an implicit conversion compiles.
vitaut
  • 49,672
  • 25
  • 199
  • 336
Howard Hinnant
  • 206,506
  • 52
  • 449
  • 577
  • Thank you for your answer. I think high_resolution_clock still can be legally used in this way: `typedef typename std::conditional::type hr_steady_clock;`. – anton_rh May 26 '16 at 06:10
  • @anton_rh: True enough. For every implementation I'm aware of, that is a complicated way to say `using hr_steady_clock = std::chrono::steady_clock;`. – Howard Hinnant May 26 '16 at 13:46
  • 3
    Can you elaborate on the "Avoid uses of `.count()` and `.time_since_epoch()`" part? What caveats are hidden behind these functions? – Julien Oct 17 '18 at 07:15
  • 5
    @Julien: `.count()` and `.time_since_epoch()` are much like `reinterpret_cast`. They change the type so drastically as to change the meaning of the value. Sometimes that is necessary. But if you can avoid it, `chrono` will catch more logical errors for you at compile time by making sure your use of the time units is consistent. – Howard Hinnant Oct 17 '18 at 14:07
  • One reason why everyone is using `.count()` is probably that all the examples on cppreference.com use it as well. E.g. [`chrono::duration`](https://en.cppreference.com/w/cpp/chrono/duration) – paleonix May 25 '22 at 11:03
  • 4
    Yep. As we transition to C++20, `.count()` should become a lot less necessary. For example you'll be able to print out your durations without `.count()`. – Howard Hinnant May 25 '22 at 13:55
  • 1
    @HowardHinnant: Great if all you want is a time-stamp. But if all you wanted was a timestamp, you wouldn't be using high_resolution_clock. How do you answer the question of "how long?" if you don't use duration and/or count? – Robin Davies Sep 30 '22 at 15:07
  • 5
    I use `steady_clock` for timings that I expect to be brief, and otherwise `system_clock`. "Brief" is a vague term. Call it 1s or 1min. I _do_ use `duration`. But I only use `duration_cast` if I desire truncate towards zero behavior. Don't use `duration_cast` to (for example) convert seconds to milliseconds. Implicit conversion will work fine for that. Use `duration_cast` to convert milliseconds to seconds. Don't use `.count()` unless you need it for a print statement. And even then, I prefer C++20, or https://github.com/HowardHinnant/date/blob/master/include/date/date.h instead. – Howard Hinnant Sep 30 '22 at 16:03
  • 2
    chrono video 1h tutorial: https://www.youtube.com/watch?v=P32hvk8b13M – Howard Hinnant Sep 30 '22 at 16:04
4

I would suggest that single uses of the high res clock could lie.

If your algorithm makes use of many measurements then any error should average-out and you should be able to measure very small intervals.

I've used the high resolution clock to build timelines in network events where otherwise my intervals would have all been 0. :)

Finally, consider that while your system clock might not be steady, if your high res clock is stead, that greatly simplifies some games you have to play to make sure time always flows forwards.

In summary, yeah, it can fail, but when you have it, it's very helpful. Lots of samples are your friends. :)

Sam
  • 2,939
  • 19
  • 17