Can someone decipher whether timeGetTime() or QueryPerformanceCounter/QueryPerformanceFrequency has lower overhead or/and accuracy?

Question

The idea is that an existing project uses timeGetTime() (for windows targets) quite frequently.

milliseconds = timeGetTime();

Now, this could be replaced with

double tmp = (double) lpPerformanceCount.QuadPart/ lpFrequency.QuadPart; 
milliseconds = rint(tmp * 1000);

with lpPerformanceCount.QuadPart and lpFrequency.QuadPart being taken from the use of a single call to QueryPerformanceCounter() and QueryPerformanceFrequency().

I know Windows' internals are kind of voodoo, but can someone decipher which of the two is more accurate or/and has more overheads?

I suspect accuracy might be same but QueryPerformanceCounter might have less overheads. But I have no hard data to back it up.

Of course I wouldn't be surprised if the opposite is true.

If overheads are tiny in any way I would be more interested on whether there's any difference in accuracy.

Answer 1

The accuracy of timeGetTime() is variable, based on the last used timeBeginPeriod. It will never be better than one millisecond. QueryPerformanceCounter is variable too, depending on hardware support. It will never be worse than about a microsecond.

Neither of them have notable overhead, QPC is probably a bit heavier. Whether that's significant to you is quite unclear from your question. I doubt it, but measure. With QPC.

Answer 2

Be careful: QueryPerformanceCounter may be processor dependent. If your thread grabs the perf counter on one CPU, and ends up on another CPU before it grabs again, the results may not be reliable. See the MSDN entry.

Answer 3

Accuracy is better on QPC. timeGetTime is accurate within the 1-10ms range (and its resolution is no finer than 1ms), whereas QPC can give you accuracy in the microsecond range.

The overhead varies. QPC uses the best hardware timer available. That may be some lightweight one built into the CPU, or it may have to go out to the motherboard which adds significant latency. And it might be made more expensive by having to go through a driver correcting for the timer hardware being buggy.

But neither is prohibitively expensive. If you're not going to call the timer millions of times per second, the overhead is insignificant for both.