关于settimer函数的使用，得出来的运行时间不太对

settimer（1，10，null）
然后在ontimer中有一个全局变量count来记录ontimer触发次数
然后记录运行时间为time=（count*10）/1000；
为什么这个得到的已经运行的时间偏慢啊
就是现实的一秒时间变得有点长啊

12 个解决方案

#1

SetTimer这种定时是由系统维护，消息机制出发的定时，所以有延迟不准确。你可以试试多媒体定时器

#2

SetTImer的精度是不高的，一般的15ms左右， 而且WM_TIMER优先级最低，只要消息缓冲区非空，他就不会被投递

可以考虑使用多媒体定时器  参看我的博客  高精度多媒体时钟应用类 .

#3

如LS所说,WM_TIMER优先级太低,做准确定时很不靠谱.

#4

如果一个任务长时间占CPU,那么你的定时器就不会被触发,所以不准是正常的.按楼上说的用多媒体定时器:开一个线程,在线程里计算多媒体时间差值 

#5

用线程吧，这个比OnTimer准..

#6

计时用 DWORD WINAPI GetTickCount(void); 函数。

DWORD tc = GetTickCount();
//...
tc = GetTickCount() - tc;

这个计时无论在哪儿用都是比较准的。

#7

正常的，SetTimer只是定时产生WM_TIMER消息到消息队列末尾而已，而且相同的还会合并，就是如果你5秒钟都没来得及处理WM_TIMER消息的话，最后只能处理一个。

想知道运行时间很简单，用GetProcessTimes就能得到进程的启动时间，和现在时间一减就是了，这个是最精确的。

GetTickCount虽然也能用于计时，是操作系统启动后的毫秒数，但由于内部计数是32位的，所以31天多后就会重新计数，不适合用于长时间计时。代替GetTickCount可以用GetSystemTime获取系统时间，然后转成FILETIME就能直接相加减。

#8

照理说，Timer如果及时处理的话，照你那样用也不会出现什么误差，但关键问题就是，你的周期设得太短了，才10ms，Windows系统线程切换的最小时间片是20ms，你这样注定得不到及时处理，设成1s周期，只要CPU负载不是太重，按照你原始的处理也应该没什么大问题，虽然肯定不精确

#9

Timer的精度不够，GetTickCount  ， timeGetTime ， QueryPerformanceFrequency 等都行，精度比较高

#10

Timer精度不够

#11

引用 6 楼 gordon3000 的回复:

计时用 DWORD WINAPI GetTickCount(void); 函数。
C/C++ code?123DWORD tc = GetTickCount();//...tc = GetTickCount() - tc;
这个计时无论在哪儿用都是比较准的。

这个不错。

#12

引用 6 楼 gordon3000 的回复:

计时用 DWORD WINAPI GetTickCount(void); 函数。

DWORD tc = GetTickCount();
//...
tc = GetTickCount() - tc;

这个计时无论在哪儿用都是比较准的。

这种方案是不是会占用很多cpu的资源？