GetTickCount

GetTickCount is a function in the Windows API. It takes no (void) parameters and returns the time since the system was started.

Common usage

GetTickCount works on all windows platforms that supports the Windows API. It measures time in milliseconds (though it does not have millisecond resolution; its value is typically updated every 16ms), and is precise enough to measure the speed of code execution and algorithms. "However", it is unreliable when used to determine the time since the system was started, because of the Rollback.

Including

GetTickCount is used in C# or C++, with Microsoft Windows SDK linked in the project and Windows API included in the header through: "#include ".

It may also be imported directly from kernel32.dll, using the standard API declaration for respective language. For example, in Microsoft Visual Basic 2008, the declaration can look like this:

Declare Function GetTickCount Lib "kernel32.dll" () As Integer

Rollback

A so called rollback, happens when the number of "ticks" or milliseconds since the system boot reaches the binary maximum storage space of 32 bit. The rollback will appear differently whether the coder has chosen to store the return DWORD in an unsigned or signed 32 bit integer. When this happens with an unsigned integer, it starts all over again on zero. In a standard, signed integer, it will rollback to the lowest possible negative value, and then keep counting upwards.

Arithmetic problems

If this function is used to measure the time taken from point A to point B, (such as the time taken C = B - A), and this is calculated through standard unchecked computer arithmetics, the rollback won't matter, since the topmost bits will be discarded. This can be shown in an example where matters are simplified by pretending GetTickCount returns a 5 bit value, making the highest possible value 31 (2^5-1) before it would rollback to 0 (=32). If this algorithm is used to retrieve a time interval passing over the rollback between A=30 and B=2 would leave us 2-30 = -28. -28 can't be applied in a 5 bit system, because it would require a 6:th bit that marks that it's negatively signed. Since this bit is out of range, it is discarded, and the 5 remaining bits equals 4.

Therefore, using this with unchecked arithmetics is not a problem, as long as the period of time measured is not longer than 2^32 milliseconds=49.71 days. Attempts to measure timespans larger than this would result in the result being "cut" such as (actual timespan) modulus 2^32.

However, if this method is used with checked Arithmetics which is common in most high-level languages such as Visual Basic and MC++, it could face a possible run time overflow error since high level bits are simply not discarded, but used to detect overflows. This is a very subtle error since it only happens on systems running for over 49 days.

Avoiding rollback examples

To avoid rollback errors the coder can for example use another API GetTickCount64, which works exactly the same as GetTickCount, but it returns a 64 bit integer instead. However, this solution will limit the application to run on Microsoft Windows Vista or later platforms. There are also other ways to avoid the overflow error, for example making a function which takes two 32b integers, A and B and converts them to 64 bit, subtracts them, and manually discards the top bits by bitmasking with 0xFFFFFFFF. This is an example using Microsoft Visual Basic 2008 code:

Public Function SafeSubtract(ByVal A As Int64, ByVal B As Int64) As Integer Return (A - B) And &HFFFFFFFF End Function

References

* [http://msdn2.microsoft.com/en-us/library/ms724408.aspx Article about GetTickCount in the MSDN library]
* [http://msdn2.microsoft.com/en-us/library/ms724411.aspx Article about GetTickCount64 in the MSDN library]

External links

* [http://blogs.msdn.com/sloh/archive/2005/04/05/405724.aspx Truth and fiction about GetTickCount]