kode54 and paper suggested QueryPerformanceCounter.

QueryPerformanceCounter (QPC) is unreliable in every version of Windows with the "correct" hardware (i.e. hardware that does not conform to Microsoft's invalid assumptions). It is less of a problem starting with roughly about Windows 8 because the hardware is rather rare/uncommon with this Windows version.

Microsoft assumes synchronized TSC accross different cores even if the hardware does not provide it. The fluctuations are rather catastrophic on early Athlon 64 Dual Cores, or early Pentium 4/D systems, or any multi-socket system, where power management frequency scaling scales the TSC differently between cores.

And there is another problem with QPC: on the subset of old systems where Microsoft correctly does not assume synchronized TSC, it can fall back to ACPI HPET or ACPI PMTIMER, which can be awfully slow to read, and will be a measurable performance overhead in practice.

The unreliability is not that much of a problem though when QPC (or RDTSC) is only used to display a value to the user. It is highly problematic when doing any sort of scheduling or automatic performance tuning based on it though.

Half of the truth is documented at https://learn.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps, the other half is scattered across the internet and personal experience. On all my systems from Windows 2000 through Windows 8.1, QPC was non-monotonic and/or slow on about 80% of them. I have not checked recently with Windows 10 or Windows 11.

Microsoft C++ STL choosing QPC as the implementation backend for std::chrono::steady_clock is highly questionable IMHO, given that this is supposed to be compatible with systems back to Windows XP SP3.

QPC in the audio hot path (i.e. twice per period per plugin) gets a hard no from me, this will kill performance on systems that we likely cannot easily test on any more.

I would strongly suggest using raw RDTSC for this purpose. Even though it has all the same problems that QPC has (and in some cases is even worse), it does not destroy performance on some systems that we cannot name or list.