timeGetTime and GetTickCount

[Dale]

What is the functional difference, if any, between these two API calls? I
looked them both up in API-Guide, and they appear to provide the same
information, namely the number of milliseconds since Windows was started.

Just curious.

Thanks for any information.

[Tim]

I have notes on this I wrote down a long time ago... this was back in VB4 days,
and not sure if they are still relevant, or whether it's operating system
related or VB version related.

GetTickCount is not so fast and not so accurate; but it works without including
the winmm library.
The GetTickCount function retrieves the number of milliseconds that have elapsed
since the system was started. It is limited to the resolution of the system
timer. If you need a higher resolution timer then you will have to use a
multimedia timer or a high-resolution timer

TimeGetTime is second fastest and a LOT more accurate than GetTickCount. The
GetTickCount can be off by as much as 55ms. This one is a higher resolution
timer, and is generally only off ±5ms.

I get the idea that using the Winmm library has more overhead in calling the
function than it does in TimeGetTime, which utilizes the kernel32 library. I
imagine that the only time this will be an issue is if you are relying on
near-accuracy and are calling the procedures in sequential order many times.

I hope this is of some help.

Tim

Post by Dale
What is the functional difference, if any, between these two API calls? I
looked them both up in API-Guide, and they appear to provide the same
information, namely the number of milliseconds since Windows was started.
Just curious.
Thanks for any information.
--
Dale

[Tim]

Post by Tim
I get the idea that using the Winmm library has more overhead in calling the
function than it does in TimeGetTime, which utilizes the kernel32 library. I
imagine that the only time this will be an issue is if you are relying on
near-accuracy and are calling the procedures in sequential order many times.

I apologize, I was typing and reading and typing and reading, and I skipped
around by accident without realizing it.

The timeGetTime uses the winmm.dll, which has more overhead than using the
counterpart, GetTickCount which uses the kernel32.dll file.

[Dale]

Post by Tim
I apologize, I was typing and reading and typing and reading, and I skipped
around by accident without realizing it.
The timeGetTime uses the winmm.dll, which has more overhead than using the
counterpart, GetTickCount which uses the kernel32.dll file.

Thanks for the response. Am I correct that either of these calls would be
more accurate than the built-in VB6 Timer?

[Tim]

actually, my internal servers stay up for more than 42 days. My "internet

enabled" systems would

too if i didnt have to do windows updates once a week and keep rebooting them.

Which is why I said workstations, not servers :-) And I totally agree with you.
So far, my WinXP workstation has been up and running for 4 days straight.... but
I see there's a critical update I haven't installed yet. So, reboot, here I
come!

[Dick Grier]

Hi,

GetTickCount (in general) is limited to an actual resolution of 55 mS. The
timeGetTime API can achieve 1 mS resolution, though it may default to 10 mS
under some versions of Windows.