<chrono>: Performance: consider GetSystemTimeAsFileTime instead of GetSystemTimePreciseAsFileTime

[AlexGuteniev]

Currently std::chrono::system_clock::now() is GetSystemTimePreciseAsFileTime() on Vista+

Consider just using GetSystemTimeAsFileTime(), as it is way faster, as it does not use QueryPerformanceCounter() uderneath.

If user wants resolution, they would call high_resolution_clock, which is steady_clock, and it directly calls QueryPerformanceCounter().

Potentially breaking change, but not ABI-breaking.

[BillyONeal]

@StephanTLavavej wasn't there an internal version of this bug?

[StephanTLavavej]

Not to my knowledge - I intentionally used Precise as non-Precise is so coarse-grained. I wasn't aware that Precise was slower; my understanding was that QPC was very fast.

Can you quantify what "way faster" is?

[BillyONeal]

@StephanTLavavej Maybe I'm remembering DevCom-184829 which was filed against the UCRT

[StephanTLavavej]

Oh yeah, the VM interaction. system_clock doesn't have second granularity, so the concern with time() doesn't apply.

[AlexGuteniev]

Simple performance test:

#include <chrono>
#include <iostream>
#include <Windows.h>

int main()
{
    using namespace std::chrono;
    constexpr std::size_t N = 1'000'000;

    FILETIME ft;

    auto start_time_point = steady_clock::now();
    for (std::size_t i = 0; i != N; i++) {
        ::GetSystemTimeAsFileTime(&ft);
    }
    auto duration_ms = duration_cast<duration<double, std::milli>>(
        steady_clock::now() - start_time_point);
    std::cout << duration_ms.count() << " ms GetSystemTimeAsFileTime\n";

    start_time_point = std::chrono::steady_clock::now();
    for (std::size_t i = 0; i != N; i++) {
        ::GetSystemTimePreciseAsFileTime(&ft);
    }
    duration_ms = duration_cast<duration<double, std::milli>>(
        steady_clock::now() - start_time_point);
    std::cout << duration_ms.count() << " ms GetSystemTimePreciseAsFileTime\n";
}

Result on my system:

1.8054 ms GetSystemTimeAsFileTime
18.7456 ms GetSystemTimePreciseAsFileTime

I believe that results would vary. It all depends on performance of rdtsc instruction on a given CPU.
QPC is wrapper for rdtsc.

I intentionally used Precise as non-Precise is so coarse-grained

This is also true, so I'm not sure if 10 times performance difference advocates this change.

[AlexGuteniev]

Note that the same way steady_clock could be separated from high_resolution_clock and use GetTickCount64.

(It is actually my production case; I needed fast and steady clock. Luckily, implementing Clock based on GetTickCount64 is trivial, as the unit is hard-defined)

[Lectem]

Note that the same way steady_clock could be separated from high_resolution_clock and use GetTickCount64.

While it could, I think it would be better to keep using QPC for steady_clock, as high_resolution_clock is kind of shunned now (even Howard Hinnant said it was a mistake to standardize it). As a result, quite a bit of code expects steady_clock to be high resolution.

[StephanTLavavej]

We talked about this in our weekly meeting, and we believe that making a runtime behavior change here would be destabilizing. We suggest writing a clock powered by GetSystemTimeAsFileTime if you want that function's behavior.