Best way to get elapsed time in miliseconds in windows

Question

I'm trying to do it using two FILETIMEs, casting them to ULONGLONGs, substracting the ULONGLONGs, and dividing the result by 10000. But it's pretty slow, and I want to know if there is a better way to do it.I use c++ with visual studio 2008 express edition. This is what I'm using:

FILETIME filetime,filetime2;
GetSystemTimeAsFileTime(&filetime);
Sleep(100);
GetSystemTimeAsFileTime(&filetime2);
ULONGLONG time1,time2;
time1 = (((ULONGLONG) filetime.dwHighDateTime) << 32) + filetime.dwLowDateTime;
time2 = (((ULONGLONG) filetime2.dwHighDateTime) << 32) + filetime2.dwLowDateTime;
printf("ELAPSED TIME IN MS:%d",(int)((time2-time1)/10000));

Answer 1

Use QueryPerformanceCounter.

long long milliseconds_now() {
    static LARGE_INTEGER s_frequency;
    static BOOL s_use_qpc = QueryPerformanceFrequency(&s_frequency);
    if (s_use_qpc) {
        LARGE_INTEGER now;
        QueryPerformanceCounter(&now);
        return (1000LL * now.QuadPart) / s_frequency.QuadPart;
    } else {
        return GetTickCount();
    }
}

// Somewhere else...
    // ...
    long long start = milliseconds_now();
    // ....
    long long elapsed = milliseconds_now() - start;

Answer 2

Generally timeGetTime() is best for timing game logic - GetTickCount isn't quite high enough resolution, and QPC & RDTSC are a lot more trouble than they are worth for that purpose.

For profiling on the other hand, either RDTSC or QPC can be quite worthwhile. I prefer RDTSC over QPC, though microsoft recommends QPC.

The four common time functions I use on win32:

GetTickCount() returns the current time in milliseconds relative to some arbitrary zero (usually, though not always system boot time), as a 32 bit integer (so it wraps every 49 days or so). It is usually the fastest method to measure a time. Unfortunately it is low resolution - typically it only updates 64 times per second. Contrary to popular rumor, calling timeBeginPeriod(1) will not increase its resolution on any system I've tested that on. There is also a 64 bit variant if you're worried about it wrapping.

timeGetTime() returns the current time in milliseconds relative to some arbitrary zero, as a 32 bit value (so it wraps after 49 days or so). It's not as fast as GetTickCount, but still pretty reasonable. It can be accurate to a single millisecond, though that may require calling timeBeginPeriod(1) first. Using timeGetTime requires linking against winmm.lib and including Mmsystem.h.

QueryPerformanceCounter() returns the current time in arbitrary units as a 64 bit integer. You can figure out what the units are by calling QueryPerformanceFrequency(), and the units will not change (absent a reboot). The underlying implementation of this varies widely, and each implementation has its own quirks and bugs that may occur on some hardware, making this obnoxious to use in widely deployed applications. Some implementations are very slow, others are reasonable, though none are as fast as GetTickCount or even timeGetTime. Typically timing resolution is better than 1 microsecond, though not necessarily much better.

RDTSC is an x86 / x64 assembly language opcode that returns the current time in units of CPU cycles (ie as a 64 bit integer. On some compilers it can be accessed as an intrinsic (__rdstc), on others you'll need inline asm. Its speed varies a bit between CPUs but is usually pretty reasonable - typically significantly faster than QueryPerformanceCounter but not as fast as GetTickCount. Unfortunately it has a few quirks - not as many as QueryPerformanceCounter, but still a lot more than the lower resolution time functions. It can sometimes run backwards on multicore CPUs when you switch cores due to imperfect synchronization between cores, the units are difficult to figure out, and the units can change in mid-timing due to power management changing the rate of the CPU clock.

Note that each of these four methods can drift relative to the other three - there is no clear authoritative flow of time.

Answer 3

To answer your question : there is no "best" solution to measure time. Every method has its own advantages/disadvantages. It all depends of your needs.

Here is several questions you should ask yourself before choosing one solution :

• timer resolution. Do you really need a precise timer (< 1ms) or can you live with something less precise (eg : 10ms precision) ?

• cpu cost. some methods will require more cpu than some others. generally more precise timers require more cpu. also, calling some methods can have consequences for the other applications (eg : calling timeBeginPeriod(1) in win32 stress the os and reduce laptop battery life)

• works with SMP. some methods use specific CPU data (eg: number of cycles elapsed) and can have some problems in multiprocessor environments.

• works with CPU that have power saving feature. Some cpu have ability to change frequency over the time, which can cause some trouble to some timing methods.

For the example you give, I would use a combination of QueryPerformanceCounter() / QueryPerformanceFrequency().

Also please note that in the example you give sleep(100) can actually wait more than 100ms. So even with very precise timer it can returns some results other than 100ms.

Answer 4

I just did some benchmarks, and there is pretty much no good reason to use timeGetTime anymore. QueryPerformanceCounter is very slightly faster, and much more precise.

Then there's GetTickCount, which is nearly instantaneous, since all it does is read back some value that the OS changes during process scheduling. The value stays the same for over 15ms at a time, and is not recommended for anything besides very coarse timing.

Answer 5

Take a look at the GetTickCount() function it's return value is the number of milliseconds that have elapsed since the system was started.

unsigned int Last = 0;
unsigned int Now = 0;
Last = GetTickCount();
//...Run your functions..
Now = GetTickCount();
printf("Elapsed Time in Milliseconds: %i",(Now-Last));