Todo on this page:

  • add useful forum links (e.g. with code snippets)

A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | 0-9

The QueryPerformanceCounter is the most precise time stamp counter on Windows systems.

It's useful e.g. for FPS calculations.


  • The value of QueryPerformanceFrequency never changes, while a system is running.
  • Aware: It's possible that QueryPerformanceFrequency returns 0 on some hardware systems.
  • Aware: The difference between an older and a newer value of the QueryPerformanceCounter can be negative. (This can happen when the thread moves from one CPU core to an other.)

Forum quotes:

mstoyke (2010) wrote:

Using the QueryPerformanceCounter functions can cause problems on multi-core CPUs, at least there were some serious problems in the past. I don't know if the .NET Stopwatch class is aware of the problem and contains a fix.

On most machines you should be fine using any of these methods. If you have strange effects, just remember that you might have to take care of these bugs.

A little more detail:
On multi-core CPUs the performance counter on different cores can have different values. If the scheduler changes your program flow to another core, you might get strange readings like large differences between calls. If you create a time delta every frame (currentTimeStamp - lastTimeStamp) and you get negative values, you just encountered this problem.

The easiest way is to use a background thread with an affinity mask that binds it to only one core. So the functions will always use the same performance counter and the problem is solved. You'll have to do this in C or C++ code, because .NET has its own internal scheduler that is independent of the system scheduler and you can't change the affinity mask in a reliable way.

See also: