只要问题可以解决，分数不够可以在加的。
22 个解决方案
#1
对于用户的操作来说，Timer已经很精确了
要更精确，那就开一个线程，循环，取微秒级时间
要更精确，那就开一个线程，循环，取微秒级时间
#2
帮你顶 这个问题我还真不知道
向各位学习了
继续关注
向各位学习了
继续关注
#3
timer可以精确到0.001秒 我想对于做时钟已经足够了，自己做timer可能不是很好做啊
#4
什么叫精确呢?
#5
timer不行.根本不准.你可以用timer跑10分钟你看差多少时间.
目前我用的方法是开线程取系统时间.
目前我用的方法是开线程取系统时间.
#6
就知道 timer 其他的呢 没多了解过 顶下
#7
用Timer控件就可以啊 一般不会有误差啊
如果用线程的话道理和Timer一样，用起来操作还麻烦
当然线程可以用于一些较复杂的计时操作
如果用线程的话道理和Timer一样，用起来操作还麻烦
当然线程可以用于一些较复杂的计时操作
#8
没用过，关注！！
#9
Timer 控件响应时间的流逝。它们独立于用户，编程后可用来在一定的时间间隔执行操作。此控件的一个一般用处是检查系统时钟，判断是否该执行某项任务。对于其它后台处理， Timer 控件也非常有用。
每个 Timer 控件都有 Interval 属性，指定定时器事件之间的毫秒数。除非禁止此属性，否则定时器在大致相等的时间间隔不断接受事件（称作定时器事件会更贴切）。
在为 Timer 控件编程时应考虑对 Interval 属性的几条限制：
如果应用程序或其它应用程序正在进行对系统要求很高的操作─ 例如长循环、高强度的计算或者正在访问驱动器、网络或端口─ 则应用程序定时器事件的间隔可能比 Interval 属性指定的间隔长。
间隔的取值可在 0 到 64,767 之间（包括这两个数值），这意味着即使是最长的间隔也不比一分钟长多少（大约 64.8 秒）。
间隔并不一定十分准确。要保证间隔准确，应在需要时才让定时器检查系统时钟，而不在内部追踪积聚的时间。
系统每秒生成 18 个时钟信号─ 所以即使用毫秒衡量 Interval 属性，间隔实际的精确度不会超过 18 分之一秒
（参考MSDN）
每个 Timer 控件都有 Interval 属性，指定定时器事件之间的毫秒数。除非禁止此属性，否则定时器在大致相等的时间间隔不断接受事件（称作定时器事件会更贴切）。
在为 Timer 控件编程时应考虑对 Interval 属性的几条限制：
如果应用程序或其它应用程序正在进行对系统要求很高的操作─ 例如长循环、高强度的计算或者正在访问驱动器、网络或端口─ 则应用程序定时器事件的间隔可能比 Interval 属性指定的间隔长。
间隔的取值可在 0 到 64,767 之间（包括这两个数值），这意味着即使是最长的间隔也不比一分钟长多少（大约 64.8 秒）。
间隔并不一定十分准确。要保证间隔准确，应在需要时才让定时器检查系统时钟，而不在内部追踪积聚的时间。
系统每秒生成 18 个时钟信号─ 所以即使用毫秒衡量 Interval 属性，间隔实际的精确度不会超过 18 分之一秒
（参考MSDN）
#10
关注
#11
同意9楼
在Timer事件中检查系统时间，而不用累加。
在Timer事件中检查系统时间，而不用累加。
#12
要高精度可以使用 System.threading.Timer
至于那些说 Timer 不准确的， 九成是用了 System.Windows.Forms.Timer， 它是走在主线程上的时钟，受用户代码影响，能准吗
至于那些说 Timer 不准确的， 九成是用了 System.Windows.Forms.Timer， 它是走在主线程上的时钟，受用户代码影响，能准吗
#13
Timer有3种。Form.Timer肯定是不精确啦，但是
Timer.Timer和Thread.Timer还是比较精确的~
Timer.Timer和Thread.Timer还是比较精确的~
#15
用线程可以计时，只是线程操作控件需要委托
#16
我要做的队时间要求非常高。是做体育比赛项目的。要求精确到毫秒，所以把打算用timer控件，我想通过api函数来获得时间。大家有什么意见。
#17
ding
#18
用线程
开等待时间做时间间隔
开等待时间做时间间隔
#19
想绝对精确么？
楼主可以试试如下方式：
你需要使用WIN32函数gettickcount()函数，在C#文件里面做一下声明就好了，放到需要调用的类定义里面。
[DllImport("Kernel32.dll")]
public static extern int GetTickCount ();
就可以了。
这个函数就是毫秒级的。
更为方便的做法，你直接在需要计时的地方直接调用：System.Environment.TickCount 这个域值，这个属性值在底层会调用上述的Gettickcount方法。这个方便。开始时计一个这个域值，结束时计一个这个域值，然后两值相减就是毫秒数。这个是最方便最简单的了。
还有，建议，你要是做计时，一定要开新线程，而且一定要事先开好了挂起来，按开始时恢复线程，结束时挂起线程。
如果你还要更精确的，精确到CPU时钟级的，也有办法，不过，对于体育计时已经没必要了。
楼主可以试试如下方式：
你需要使用WIN32函数gettickcount()函数，在C#文件里面做一下声明就好了，放到需要调用的类定义里面。
[DllImport("Kernel32.dll")]
public static extern int GetTickCount ();
就可以了。
这个函数就是毫秒级的。
更为方便的做法，你直接在需要计时的地方直接调用：System.Environment.TickCount 这个域值，这个属性值在底层会调用上述的Gettickcount方法。这个方便。开始时计一个这个域值，结束时计一个这个域值，然后两值相减就是毫秒数。这个是最方便最简单的了。
还有，建议，你要是做计时，一定要开新线程，而且一定要事先开好了挂起来，按开始时恢复线程，结束时挂起线程。
如果你还要更精确的，精确到CPU时钟级的，也有办法，不过，对于体育计时已经没必要了。
#20
10毫秒以上精度的Timer足以
更精确的好像是取CPU主频，没搞过不太清楚
更精确的好像是取CPU主频，没搞过不太清楚
#21
大家有没有这方面的代码啊，我想借鉴下。
#22
使用CPU时间戳进行高精度计时
对关注性能的程序开发人员而言，一个好的计时部件既是益友，也是良师。计时器既可以作为程序组件帮助程序员精确的控制程序进程，又是一件有力的调试武器，在有经验的程序员手里可以尽快的确定程序的性能瓶颈，或者对不同的算法作出有说服力的性能比较。
在Windows平台下，常用的计时器有两种，一种是timeGetTime多媒体计时器，它可以提供毫秒级的计时。但这个精度对很多应用场合而言还是太粗糙了。另一种是QueryPerformanceCount计数器，随系统的不同可以提供微秒级的计数。对于实时图形处理、多媒体数据流处理、或者实时系统构造的程序员，善用QueryPerformanceCount/QueryPerformanceFrequency是一项基本功。
本文要介绍的，是另一种直接利用Pentium CPU内部时间戳进行计时的高精度计时手段。以下讨论主要得益于《Windows图形编程》一书，第15页－17页，有兴趣的读者可以直接参考该书。关于RDTSC指令的详细讨论，可以参考Intel产品手册。本文仅仅作抛砖之用。
在Intel Pentium以上级别的CPU中，有一个称为“时间戳（Time Stamp）”的部件，它以64位无符号整型数的格式，记录了自CPU上电以来所经过的时钟周期数。由于目前的CPU主频都非常高，因此这个部件可以达到纳秒级的计时精度。这个精确性是上述两种方法所无法比拟的。
在Pentium以上的CPU中，提供了一条机器指令RDTSC（Read Time Stamp Counter）来读取这个时间戳的数字，并将其保存在EDX:EAX寄存器对中。由于EDX:EAX寄存器对恰好是Win32平台下C++语言保存函数返回值的寄存器，所以我们可以把这条指令看成是一个普通的函数调用。像这样：
inline unsigned __int64 GetCycleCount()
{
__asm RDTSC
}
但是不行，因为RDTSC不被C++的内嵌汇编器直接支持，所以我们要用_emit伪指令直接嵌入该指令的机器码形式0X0F、0X31，如下：
inline unsigned __int64 GetCycleCount()
{
__asm _emit 0x0F
__asm _emit 0x31
}
以后在需要计数器的场合，可以像使用普通的Win32 API一样，调用两次GetCycleCount函数，比较两个返回值的差，像这样：
unsigned long t;
t = (unsigned long)GetCycleCount();
t -= (unsigned long)GetCycleCount();
《Windows图形编程》第15页编写了一个类，把这个计数器封装起来。有兴趣的读者可以去参考那个类的代码。作者为了更精确的定时，做了一点小小的改进，把执行RDTSC指令的时间，通过连续两次调用GetCycleCount函数计算出来并保存了起来，以后每次计时结束后，都从实际得到的计数中减掉这一小段时间，以得到更准确的计时数字。但我个人觉得这一点点改进意义不大。在我的机器上实测，这条指令大概花掉了几十到100多个周期，在Celeron 800MHz的机器上，这不过是十分之一微秒的时间。对大多数应用来说，这点时间完全可以忽略不计；而对那些确实要精确到纳秒数量级的应用来说，这个补偿也过于粗糙了。
这个方法的优点是：
1.高精度。可以直接达到纳秒级的计时精度（在1GHz的CPU上每个时钟周期就是一纳秒），这是其他计时方法所难以企及的。
2.成本低。timeGetTime函数需要链接多媒体库winmm.lib，QueryPerformance函数根据MSDN的说明，需要硬件的支持（虽然我还没有见过不支持的机器）和KERNEL库的支持，所以二者都只能在Windows平台下使用（关于DOS平台下的高精度计时问题，可以参考《图形程序开发人员指南》，里面有关于控制定时器8253的详细说明）。但RDTSC指令是一条CPU指令，凡是i386平台下Pentium以上的机器均支持，甚至没有平台的限制（我相信i386版本UNIX和Linux下这个方法同样适用，但没有条件试验），而且函数调用的开销是最小的。
3.具有和CPU主频直接对应的速率关系。一个计数相当于1/(CPU主频Hz数)秒，这样只要知道了CPU的主频，可以直接计算出时间。这和QueryPerformanceCount不同，后者需要通过QueryPerformanceFrequency获取当前计数器每秒的计数次数才能换算成时间。
这个方法的缺点是：
1.现有的C/C++编译器多数不直接支持使用RDTSC指令，需要用直接嵌入机器码的方式编程，比较麻烦。
2.数据抖动比较厉害。其实对任何计量手段而言，精度和稳定性永远是一对矛盾。如果用低精度的timeGetTime来计时，基本上每次计时的结果都是相同的；而RDTSC指令每次结果都不一样，经常有几百甚至上千的差距。这是这种方法高精度本身固有的矛盾。
关于这个方法计时的最大长度，我们可以简单的用下列公式计算：
自CPU上电以来的秒数 = RDTSC读出的周期数 / CPU主频速率(Hz)
64位无符号整数所能表达的最大数字是1.8×10^19，在我的Celeron 800上可以计时大约700年（书中说可以在200MHz的Pentium上计时117年，这个数字不知道是怎么得出来的，与我的计算有出入）。无论如何，我们大可不必关心溢出的问题。
下面是几个小例子，简要比较了三种计时方法的用法与精度
//Timer1.cpp 使用了RDTSC指令的Timer类//KTimer类的定义可以参见《Windows图形编程》P15
//编译行：CL Timer1.cpp /link USER32.lib
#include <stdio.h>
#include "KTimer.h"
main()
{
unsigned t;
KTimer timer;
timer.Start();
Sleep(1000);
t = timer.Stop();
printf("Lasting Time: %d\n",t);
}
//Timer2.cpp 使用了timeGetTime函数
//需包含<mmsys.h>，但由于Windows头文件错综复杂的关系
//简单包含<windows.h>比较偷懒：）
//编译行：CL timer2.cpp /link winmm.lib
#include <windows.h>
#include <stdio.h>
main()
{
DWORD t1, t2;
t1 = timeGetTime();
Sleep(1000);
t2 = timeGetTime();
printf("Begin Time: %u\n", t1);
printf("End Time: %u\n", t2);
printf("Lasting Time: %u\n",(t2-t1));
}
//Timer3.cpp 使用了QueryPerformanceCounter函数
//编译行：CL timer3.cpp /link KERNEl32.lib
#include <windows.h>
#include <stdio.h>
main()
{
LARGE_INTEGER t1, t2, tc;
QueryPerformanceFrequency(&tc);
printf("Frequency: %u\n", tc.QuadPart);
QueryPerformanceCounter(&t1);
Sleep(1000);
QueryPerformanceCounter(&t2);
printf("Begin Time: %u\n", t1.QuadPart);
printf("End Time: %u\n", t2.QuadPart);
printf("Lasting Time: %u\n",( t2.QuadPart- t1.QuadPart));
}
////////////////////////////////////////////////
//以上三个示例程序都是测试1秒钟休眠所耗费的时间
//测试环境：Celeron 800MHz / 256M SDRAM
// Windows 2000 Professional SP2
// Microsoft Visual C++ 6.0 SP5
////////////////////////////////////////////////
以下是Timer1的运行结果，使用的是高精度的RDTSC指令
Lasting Time: 804586872
以下是Timer2的运行结果，使用的是最粗糙的timeGetTime API
Begin Time: 20254254
End Time: 20255255
Lasting Time: 1001
以下是Timer3的运行结果，使用的是QueryPerformanceCount API
Frequency: 3579545
Begin Time: 3804729124
End Time: 3808298836
Lasting Time: 3569712
对关注性能的程序开发人员而言，一个好的计时部件既是益友，也是良师。计时器既可以作为程序组件帮助程序员精确的控制程序进程，又是一件有力的调试武器，在有经验的程序员手里可以尽快的确定程序的性能瓶颈，或者对不同的算法作出有说服力的性能比较。
在Windows平台下，常用的计时器有两种，一种是timeGetTime多媒体计时器，它可以提供毫秒级的计时。但这个精度对很多应用场合而言还是太粗糙了。另一种是QueryPerformanceCount计数器，随系统的不同可以提供微秒级的计数。对于实时图形处理、多媒体数据流处理、或者实时系统构造的程序员，善用QueryPerformanceCount/QueryPerformanceFrequency是一项基本功。
本文要介绍的，是另一种直接利用Pentium CPU内部时间戳进行计时的高精度计时手段。以下讨论主要得益于《Windows图形编程》一书，第15页－17页，有兴趣的读者可以直接参考该书。关于RDTSC指令的详细讨论，可以参考Intel产品手册。本文仅仅作抛砖之用。
在Intel Pentium以上级别的CPU中，有一个称为“时间戳（Time Stamp）”的部件，它以64位无符号整型数的格式，记录了自CPU上电以来所经过的时钟周期数。由于目前的CPU主频都非常高，因此这个部件可以达到纳秒级的计时精度。这个精确性是上述两种方法所无法比拟的。
在Pentium以上的CPU中，提供了一条机器指令RDTSC（Read Time Stamp Counter）来读取这个时间戳的数字，并将其保存在EDX:EAX寄存器对中。由于EDX:EAX寄存器对恰好是Win32平台下C++语言保存函数返回值的寄存器，所以我们可以把这条指令看成是一个普通的函数调用。像这样：
inline unsigned __int64 GetCycleCount()
{
__asm RDTSC
}
但是不行，因为RDTSC不被C++的内嵌汇编器直接支持，所以我们要用_emit伪指令直接嵌入该指令的机器码形式0X0F、0X31，如下：
inline unsigned __int64 GetCycleCount()
{
__asm _emit 0x0F
__asm _emit 0x31
}
以后在需要计数器的场合，可以像使用普通的Win32 API一样，调用两次GetCycleCount函数，比较两个返回值的差，像这样：
unsigned long t;
t = (unsigned long)GetCycleCount();
t -= (unsigned long)GetCycleCount();
《Windows图形编程》第15页编写了一个类，把这个计数器封装起来。有兴趣的读者可以去参考那个类的代码。作者为了更精确的定时，做了一点小小的改进，把执行RDTSC指令的时间，通过连续两次调用GetCycleCount函数计算出来并保存了起来，以后每次计时结束后，都从实际得到的计数中减掉这一小段时间，以得到更准确的计时数字。但我个人觉得这一点点改进意义不大。在我的机器上实测，这条指令大概花掉了几十到100多个周期，在Celeron 800MHz的机器上，这不过是十分之一微秒的时间。对大多数应用来说，这点时间完全可以忽略不计；而对那些确实要精确到纳秒数量级的应用来说，这个补偿也过于粗糙了。
这个方法的优点是：
1.高精度。可以直接达到纳秒级的计时精度（在1GHz的CPU上每个时钟周期就是一纳秒），这是其他计时方法所难以企及的。
2.成本低。timeGetTime函数需要链接多媒体库winmm.lib，QueryPerformance函数根据MSDN的说明，需要硬件的支持（虽然我还没有见过不支持的机器）和KERNEL库的支持，所以二者都只能在Windows平台下使用（关于DOS平台下的高精度计时问题，可以参考《图形程序开发人员指南》，里面有关于控制定时器8253的详细说明）。但RDTSC指令是一条CPU指令，凡是i386平台下Pentium以上的机器均支持，甚至没有平台的限制（我相信i386版本UNIX和Linux下这个方法同样适用，但没有条件试验），而且函数调用的开销是最小的。
3.具有和CPU主频直接对应的速率关系。一个计数相当于1/(CPU主频Hz数)秒，这样只要知道了CPU的主频，可以直接计算出时间。这和QueryPerformanceCount不同，后者需要通过QueryPerformanceFrequency获取当前计数器每秒的计数次数才能换算成时间。
这个方法的缺点是：
1.现有的C/C++编译器多数不直接支持使用RDTSC指令，需要用直接嵌入机器码的方式编程，比较麻烦。
2.数据抖动比较厉害。其实对任何计量手段而言，精度和稳定性永远是一对矛盾。如果用低精度的timeGetTime来计时，基本上每次计时的结果都是相同的；而RDTSC指令每次结果都不一样，经常有几百甚至上千的差距。这是这种方法高精度本身固有的矛盾。
关于这个方法计时的最大长度，我们可以简单的用下列公式计算：
自CPU上电以来的秒数 = RDTSC读出的周期数 / CPU主频速率(Hz)
64位无符号整数所能表达的最大数字是1.8×10^19，在我的Celeron 800上可以计时大约700年（书中说可以在200MHz的Pentium上计时117年，这个数字不知道是怎么得出来的，与我的计算有出入）。无论如何，我们大可不必关心溢出的问题。
下面是几个小例子，简要比较了三种计时方法的用法与精度
//Timer1.cpp 使用了RDTSC指令的Timer类//KTimer类的定义可以参见《Windows图形编程》P15
//编译行：CL Timer1.cpp /link USER32.lib
#include <stdio.h>
#include "KTimer.h"
main()
{
unsigned t;
KTimer timer;
timer.Start();
Sleep(1000);
t = timer.Stop();
printf("Lasting Time: %d\n",t);
}
//Timer2.cpp 使用了timeGetTime函数
//需包含<mmsys.h>，但由于Windows头文件错综复杂的关系
//简单包含<windows.h>比较偷懒：）
//编译行：CL timer2.cpp /link winmm.lib
#include <windows.h>
#include <stdio.h>
main()
{
DWORD t1, t2;
t1 = timeGetTime();
Sleep(1000);
t2 = timeGetTime();
printf("Begin Time: %u\n", t1);
printf("End Time: %u\n", t2);
printf("Lasting Time: %u\n",(t2-t1));
}
//Timer3.cpp 使用了QueryPerformanceCounter函数
//编译行：CL timer3.cpp /link KERNEl32.lib
#include <windows.h>
#include <stdio.h>
main()
{
LARGE_INTEGER t1, t2, tc;
QueryPerformanceFrequency(&tc);
printf("Frequency: %u\n", tc.QuadPart);
QueryPerformanceCounter(&t1);
Sleep(1000);
QueryPerformanceCounter(&t2);
printf("Begin Time: %u\n", t1.QuadPart);
printf("End Time: %u\n", t2.QuadPart);
printf("Lasting Time: %u\n",( t2.QuadPart- t1.QuadPart));
}
////////////////////////////////////////////////
//以上三个示例程序都是测试1秒钟休眠所耗费的时间
//测试环境：Celeron 800MHz / 256M SDRAM
// Windows 2000 Professional SP2
// Microsoft Visual C++ 6.0 SP5
////////////////////////////////////////////////
以下是Timer1的运行结果，使用的是高精度的RDTSC指令
Lasting Time: 804586872
以下是Timer2的运行结果，使用的是最粗糙的timeGetTime API
Begin Time: 20254254
End Time: 20255255
Lasting Time: 1001
以下是Timer3的运行结果，使用的是QueryPerformanceCount API
Frequency: 3579545
Begin Time: 3804729124
End Time: 3808298836
Lasting Time: 3569712
#1
对于用户的操作来说，Timer已经很精确了
要更精确，那就开一个线程，循环，取微秒级时间
要更精确，那就开一个线程，循环，取微秒级时间
#2
帮你顶 这个问题我还真不知道
向各位学习了
继续关注
向各位学习了
继续关注
#3
timer可以精确到0.001秒 我想对于做时钟已经足够了，自己做timer可能不是很好做啊
#4
什么叫精确呢?
#5
timer不行.根本不准.你可以用timer跑10分钟你看差多少时间.
目前我用的方法是开线程取系统时间.
目前我用的方法是开线程取系统时间.
#6
就知道 timer 其他的呢 没多了解过 顶下
#7
用Timer控件就可以啊 一般不会有误差啊
如果用线程的话道理和Timer一样，用起来操作还麻烦
当然线程可以用于一些较复杂的计时操作
如果用线程的话道理和Timer一样，用起来操作还麻烦
当然线程可以用于一些较复杂的计时操作
#8
没用过，关注！！
#9
Timer 控件响应时间的流逝。它们独立于用户，编程后可用来在一定的时间间隔执行操作。此控件的一个一般用处是检查系统时钟，判断是否该执行某项任务。对于其它后台处理， Timer 控件也非常有用。
每个 Timer 控件都有 Interval 属性，指定定时器事件之间的毫秒数。除非禁止此属性，否则定时器在大致相等的时间间隔不断接受事件（称作定时器事件会更贴切）。
在为 Timer 控件编程时应考虑对 Interval 属性的几条限制：
如果应用程序或其它应用程序正在进行对系统要求很高的操作─ 例如长循环、高强度的计算或者正在访问驱动器、网络或端口─ 则应用程序定时器事件的间隔可能比 Interval 属性指定的间隔长。
间隔的取值可在 0 到 64,767 之间（包括这两个数值），这意味着即使是最长的间隔也不比一分钟长多少（大约 64.8 秒）。
间隔并不一定十分准确。要保证间隔准确，应在需要时才让定时器检查系统时钟，而不在内部追踪积聚的时间。
系统每秒生成 18 个时钟信号─ 所以即使用毫秒衡量 Interval 属性，间隔实际的精确度不会超过 18 分之一秒
（参考MSDN）
每个 Timer 控件都有 Interval 属性，指定定时器事件之间的毫秒数。除非禁止此属性，否则定时器在大致相等的时间间隔不断接受事件（称作定时器事件会更贴切）。
在为 Timer 控件编程时应考虑对 Interval 属性的几条限制：
如果应用程序或其它应用程序正在进行对系统要求很高的操作─ 例如长循环、高强度的计算或者正在访问驱动器、网络或端口─ 则应用程序定时器事件的间隔可能比 Interval 属性指定的间隔长。
间隔的取值可在 0 到 64,767 之间（包括这两个数值），这意味着即使是最长的间隔也不比一分钟长多少（大约 64.8 秒）。
间隔并不一定十分准确。要保证间隔准确，应在需要时才让定时器检查系统时钟，而不在内部追踪积聚的时间。
系统每秒生成 18 个时钟信号─ 所以即使用毫秒衡量 Interval 属性，间隔实际的精确度不会超过 18 分之一秒
（参考MSDN）
#10
关注
#11
同意9楼
在Timer事件中检查系统时间，而不用累加。
在Timer事件中检查系统时间，而不用累加。
#12
要高精度可以使用 System.threading.Timer
至于那些说 Timer 不准确的， 九成是用了 System.Windows.Forms.Timer， 它是走在主线程上的时钟，受用户代码影响，能准吗
至于那些说 Timer 不准确的， 九成是用了 System.Windows.Forms.Timer， 它是走在主线程上的时钟，受用户代码影响，能准吗
#13
Timer有3种。Form.Timer肯定是不精确啦，但是
Timer.Timer和Thread.Timer还是比较精确的~
Timer.Timer和Thread.Timer还是比较精确的~
#14
#15
用线程可以计时，只是线程操作控件需要委托
#16
我要做的队时间要求非常高。是做体育比赛项目的。要求精确到毫秒，所以把打算用timer控件，我想通过api函数来获得时间。大家有什么意见。
#17
ding
#18
用线程
开等待时间做时间间隔
开等待时间做时间间隔
#19
想绝对精确么？
楼主可以试试如下方式：
你需要使用WIN32函数gettickcount()函数，在C#文件里面做一下声明就好了，放到需要调用的类定义里面。
[DllImport("Kernel32.dll")]
public static extern int GetTickCount ();
就可以了。
这个函数就是毫秒级的。
更为方便的做法，你直接在需要计时的地方直接调用：System.Environment.TickCount 这个域值，这个属性值在底层会调用上述的Gettickcount方法。这个方便。开始时计一个这个域值，结束时计一个这个域值，然后两值相减就是毫秒数。这个是最方便最简单的了。
还有，建议，你要是做计时，一定要开新线程，而且一定要事先开好了挂起来，按开始时恢复线程，结束时挂起线程。
如果你还要更精确的，精确到CPU时钟级的，也有办法，不过，对于体育计时已经没必要了。
楼主可以试试如下方式：
你需要使用WIN32函数gettickcount()函数，在C#文件里面做一下声明就好了，放到需要调用的类定义里面。
[DllImport("Kernel32.dll")]
public static extern int GetTickCount ();
就可以了。
这个函数就是毫秒级的。
更为方便的做法，你直接在需要计时的地方直接调用：System.Environment.TickCount 这个域值，这个属性值在底层会调用上述的Gettickcount方法。这个方便。开始时计一个这个域值，结束时计一个这个域值，然后两值相减就是毫秒数。这个是最方便最简单的了。
还有，建议，你要是做计时，一定要开新线程，而且一定要事先开好了挂起来，按开始时恢复线程，结束时挂起线程。
如果你还要更精确的，精确到CPU时钟级的，也有办法，不过，对于体育计时已经没必要了。
#20
10毫秒以上精度的Timer足以
更精确的好像是取CPU主频，没搞过不太清楚
更精确的好像是取CPU主频，没搞过不太清楚
#21
大家有没有这方面的代码啊，我想借鉴下。
#22
使用CPU时间戳进行高精度计时
对关注性能的程序开发人员而言，一个好的计时部件既是益友，也是良师。计时器既可以作为程序组件帮助程序员精确的控制程序进程，又是一件有力的调试武器，在有经验的程序员手里可以尽快的确定程序的性能瓶颈，或者对不同的算法作出有说服力的性能比较。
在Windows平台下，常用的计时器有两种，一种是timeGetTime多媒体计时器，它可以提供毫秒级的计时。但这个精度对很多应用场合而言还是太粗糙了。另一种是QueryPerformanceCount计数器，随系统的不同可以提供微秒级的计数。对于实时图形处理、多媒体数据流处理、或者实时系统构造的程序员，善用QueryPerformanceCount/QueryPerformanceFrequency是一项基本功。
本文要介绍的，是另一种直接利用Pentium CPU内部时间戳进行计时的高精度计时手段。以下讨论主要得益于《Windows图形编程》一书，第15页－17页，有兴趣的读者可以直接参考该书。关于RDTSC指令的详细讨论，可以参考Intel产品手册。本文仅仅作抛砖之用。
在Intel Pentium以上级别的CPU中，有一个称为“时间戳（Time Stamp）”的部件，它以64位无符号整型数的格式，记录了自CPU上电以来所经过的时钟周期数。由于目前的CPU主频都非常高，因此这个部件可以达到纳秒级的计时精度。这个精确性是上述两种方法所无法比拟的。
在Pentium以上的CPU中，提供了一条机器指令RDTSC（Read Time Stamp Counter）来读取这个时间戳的数字，并将其保存在EDX:EAX寄存器对中。由于EDX:EAX寄存器对恰好是Win32平台下C++语言保存函数返回值的寄存器，所以我们可以把这条指令看成是一个普通的函数调用。像这样：
inline unsigned __int64 GetCycleCount()
{
__asm RDTSC
}
但是不行，因为RDTSC不被C++的内嵌汇编器直接支持，所以我们要用_emit伪指令直接嵌入该指令的机器码形式0X0F、0X31，如下：
inline unsigned __int64 GetCycleCount()
{
__asm _emit 0x0F
__asm _emit 0x31
}
以后在需要计数器的场合，可以像使用普通的Win32 API一样，调用两次GetCycleCount函数，比较两个返回值的差，像这样：
unsigned long t;
t = (unsigned long)GetCycleCount();
t -= (unsigned long)GetCycleCount();
《Windows图形编程》第15页编写了一个类，把这个计数器封装起来。有兴趣的读者可以去参考那个类的代码。作者为了更精确的定时，做了一点小小的改进，把执行RDTSC指令的时间，通过连续两次调用GetCycleCount函数计算出来并保存了起来，以后每次计时结束后，都从实际得到的计数中减掉这一小段时间，以得到更准确的计时数字。但我个人觉得这一点点改进意义不大。在我的机器上实测，这条指令大概花掉了几十到100多个周期，在Celeron 800MHz的机器上，这不过是十分之一微秒的时间。对大多数应用来说，这点时间完全可以忽略不计；而对那些确实要精确到纳秒数量级的应用来说，这个补偿也过于粗糙了。
这个方法的优点是：
1.高精度。可以直接达到纳秒级的计时精度（在1GHz的CPU上每个时钟周期就是一纳秒），这是其他计时方法所难以企及的。
2.成本低。timeGetTime函数需要链接多媒体库winmm.lib，QueryPerformance函数根据MSDN的说明，需要硬件的支持（虽然我还没有见过不支持的机器）和KERNEL库的支持，所以二者都只能在Windows平台下使用（关于DOS平台下的高精度计时问题，可以参考《图形程序开发人员指南》，里面有关于控制定时器8253的详细说明）。但RDTSC指令是一条CPU指令，凡是i386平台下Pentium以上的机器均支持，甚至没有平台的限制（我相信i386版本UNIX和Linux下这个方法同样适用，但没有条件试验），而且函数调用的开销是最小的。
3.具有和CPU主频直接对应的速率关系。一个计数相当于1/(CPU主频Hz数)秒，这样只要知道了CPU的主频，可以直接计算出时间。这和QueryPerformanceCount不同，后者需要通过QueryPerformanceFrequency获取当前计数器每秒的计数次数才能换算成时间。
这个方法的缺点是：
1.现有的C/C++编译器多数不直接支持使用RDTSC指令，需要用直接嵌入机器码的方式编程，比较麻烦。
2.数据抖动比较厉害。其实对任何计量手段而言，精度和稳定性永远是一对矛盾。如果用低精度的timeGetTime来计时，基本上每次计时的结果都是相同的；而RDTSC指令每次结果都不一样，经常有几百甚至上千的差距。这是这种方法高精度本身固有的矛盾。
关于这个方法计时的最大长度，我们可以简单的用下列公式计算：
自CPU上电以来的秒数 = RDTSC读出的周期数 / CPU主频速率(Hz)
64位无符号整数所能表达的最大数字是1.8×10^19，在我的Celeron 800上可以计时大约700年（书中说可以在200MHz的Pentium上计时117年，这个数字不知道是怎么得出来的，与我的计算有出入）。无论如何，我们大可不必关心溢出的问题。
下面是几个小例子，简要比较了三种计时方法的用法与精度
//Timer1.cpp 使用了RDTSC指令的Timer类//KTimer类的定义可以参见《Windows图形编程》P15
//编译行：CL Timer1.cpp /link USER32.lib
#include <stdio.h>
#include "KTimer.h"
main()
{
unsigned t;
KTimer timer;
timer.Start();
Sleep(1000);
t = timer.Stop();
printf("Lasting Time: %d\n",t);
}
//Timer2.cpp 使用了timeGetTime函数
//需包含<mmsys.h>，但由于Windows头文件错综复杂的关系
//简单包含<windows.h>比较偷懒：）
//编译行：CL timer2.cpp /link winmm.lib
#include <windows.h>
#include <stdio.h>
main()
{
DWORD t1, t2;
t1 = timeGetTime();
Sleep(1000);
t2 = timeGetTime();
printf("Begin Time: %u\n", t1);
printf("End Time: %u\n", t2);
printf("Lasting Time: %u\n",(t2-t1));
}
//Timer3.cpp 使用了QueryPerformanceCounter函数
//编译行：CL timer3.cpp /link KERNEl32.lib
#include <windows.h>
#include <stdio.h>
main()
{
LARGE_INTEGER t1, t2, tc;
QueryPerformanceFrequency(&tc);
printf("Frequency: %u\n", tc.QuadPart);
QueryPerformanceCounter(&t1);
Sleep(1000);
QueryPerformanceCounter(&t2);
printf("Begin Time: %u\n", t1.QuadPart);
printf("End Time: %u\n", t2.QuadPart);
printf("Lasting Time: %u\n",( t2.QuadPart- t1.QuadPart));
}
////////////////////////////////////////////////
//以上三个示例程序都是测试1秒钟休眠所耗费的时间
//测试环境：Celeron 800MHz / 256M SDRAM
// Windows 2000 Professional SP2
// Microsoft Visual C++ 6.0 SP5
////////////////////////////////////////////////
以下是Timer1的运行结果，使用的是高精度的RDTSC指令
Lasting Time: 804586872
以下是Timer2的运行结果，使用的是最粗糙的timeGetTime API
Begin Time: 20254254
End Time: 20255255
Lasting Time: 1001
以下是Timer3的运行结果，使用的是QueryPerformanceCount API
Frequency: 3579545
Begin Time: 3804729124
End Time: 3808298836
Lasting Time: 3569712
对关注性能的程序开发人员而言，一个好的计时部件既是益友，也是良师。计时器既可以作为程序组件帮助程序员精确的控制程序进程，又是一件有力的调试武器，在有经验的程序员手里可以尽快的确定程序的性能瓶颈，或者对不同的算法作出有说服力的性能比较。
在Windows平台下，常用的计时器有两种，一种是timeGetTime多媒体计时器，它可以提供毫秒级的计时。但这个精度对很多应用场合而言还是太粗糙了。另一种是QueryPerformanceCount计数器，随系统的不同可以提供微秒级的计数。对于实时图形处理、多媒体数据流处理、或者实时系统构造的程序员，善用QueryPerformanceCount/QueryPerformanceFrequency是一项基本功。
本文要介绍的，是另一种直接利用Pentium CPU内部时间戳进行计时的高精度计时手段。以下讨论主要得益于《Windows图形编程》一书，第15页－17页，有兴趣的读者可以直接参考该书。关于RDTSC指令的详细讨论，可以参考Intel产品手册。本文仅仅作抛砖之用。
在Intel Pentium以上级别的CPU中，有一个称为“时间戳（Time Stamp）”的部件，它以64位无符号整型数的格式，记录了自CPU上电以来所经过的时钟周期数。由于目前的CPU主频都非常高，因此这个部件可以达到纳秒级的计时精度。这个精确性是上述两种方法所无法比拟的。
在Pentium以上的CPU中，提供了一条机器指令RDTSC（Read Time Stamp Counter）来读取这个时间戳的数字，并将其保存在EDX:EAX寄存器对中。由于EDX:EAX寄存器对恰好是Win32平台下C++语言保存函数返回值的寄存器，所以我们可以把这条指令看成是一个普通的函数调用。像这样：
inline unsigned __int64 GetCycleCount()
{
__asm RDTSC
}
但是不行，因为RDTSC不被C++的内嵌汇编器直接支持，所以我们要用_emit伪指令直接嵌入该指令的机器码形式0X0F、0X31，如下：
inline unsigned __int64 GetCycleCount()
{
__asm _emit 0x0F
__asm _emit 0x31
}
以后在需要计数器的场合，可以像使用普通的Win32 API一样，调用两次GetCycleCount函数，比较两个返回值的差，像这样：
unsigned long t;
t = (unsigned long)GetCycleCount();
t -= (unsigned long)GetCycleCount();
《Windows图形编程》第15页编写了一个类，把这个计数器封装起来。有兴趣的读者可以去参考那个类的代码。作者为了更精确的定时，做了一点小小的改进，把执行RDTSC指令的时间，通过连续两次调用GetCycleCount函数计算出来并保存了起来，以后每次计时结束后，都从实际得到的计数中减掉这一小段时间，以得到更准确的计时数字。但我个人觉得这一点点改进意义不大。在我的机器上实测，这条指令大概花掉了几十到100多个周期，在Celeron 800MHz的机器上，这不过是十分之一微秒的时间。对大多数应用来说，这点时间完全可以忽略不计；而对那些确实要精确到纳秒数量级的应用来说，这个补偿也过于粗糙了。
这个方法的优点是：
1.高精度。可以直接达到纳秒级的计时精度（在1GHz的CPU上每个时钟周期就是一纳秒），这是其他计时方法所难以企及的。
2.成本低。timeGetTime函数需要链接多媒体库winmm.lib，QueryPerformance函数根据MSDN的说明，需要硬件的支持（虽然我还没有见过不支持的机器）和KERNEL库的支持，所以二者都只能在Windows平台下使用（关于DOS平台下的高精度计时问题，可以参考《图形程序开发人员指南》，里面有关于控制定时器8253的详细说明）。但RDTSC指令是一条CPU指令，凡是i386平台下Pentium以上的机器均支持，甚至没有平台的限制（我相信i386版本UNIX和Linux下这个方法同样适用，但没有条件试验），而且函数调用的开销是最小的。
3.具有和CPU主频直接对应的速率关系。一个计数相当于1/(CPU主频Hz数)秒，这样只要知道了CPU的主频，可以直接计算出时间。这和QueryPerformanceCount不同，后者需要通过QueryPerformanceFrequency获取当前计数器每秒的计数次数才能换算成时间。
这个方法的缺点是：
1.现有的C/C++编译器多数不直接支持使用RDTSC指令，需要用直接嵌入机器码的方式编程，比较麻烦。
2.数据抖动比较厉害。其实对任何计量手段而言，精度和稳定性永远是一对矛盾。如果用低精度的timeGetTime来计时，基本上每次计时的结果都是相同的；而RDTSC指令每次结果都不一样，经常有几百甚至上千的差距。这是这种方法高精度本身固有的矛盾。
关于这个方法计时的最大长度，我们可以简单的用下列公式计算：
自CPU上电以来的秒数 = RDTSC读出的周期数 / CPU主频速率(Hz)
64位无符号整数所能表达的最大数字是1.8×10^19，在我的Celeron 800上可以计时大约700年（书中说可以在200MHz的Pentium上计时117年，这个数字不知道是怎么得出来的，与我的计算有出入）。无论如何，我们大可不必关心溢出的问题。
下面是几个小例子，简要比较了三种计时方法的用法与精度
//Timer1.cpp 使用了RDTSC指令的Timer类//KTimer类的定义可以参见《Windows图形编程》P15
//编译行：CL Timer1.cpp /link USER32.lib
#include <stdio.h>
#include "KTimer.h"
main()
{
unsigned t;
KTimer timer;
timer.Start();
Sleep(1000);
t = timer.Stop();
printf("Lasting Time: %d\n",t);
}
//Timer2.cpp 使用了timeGetTime函数
//需包含<mmsys.h>，但由于Windows头文件错综复杂的关系
//简单包含<windows.h>比较偷懒：）
//编译行：CL timer2.cpp /link winmm.lib
#include <windows.h>
#include <stdio.h>
main()
{
DWORD t1, t2;
t1 = timeGetTime();
Sleep(1000);
t2 = timeGetTime();
printf("Begin Time: %u\n", t1);
printf("End Time: %u\n", t2);
printf("Lasting Time: %u\n",(t2-t1));
}
//Timer3.cpp 使用了QueryPerformanceCounter函数
//编译行：CL timer3.cpp /link KERNEl32.lib
#include <windows.h>
#include <stdio.h>
main()
{
LARGE_INTEGER t1, t2, tc;
QueryPerformanceFrequency(&tc);
printf("Frequency: %u\n", tc.QuadPart);
QueryPerformanceCounter(&t1);
Sleep(1000);
QueryPerformanceCounter(&t2);
printf("Begin Time: %u\n", t1.QuadPart);
printf("End Time: %u\n", t2.QuadPart);
printf("Lasting Time: %u\n",( t2.QuadPart- t1.QuadPart));
}
////////////////////////////////////////////////
//以上三个示例程序都是测试1秒钟休眠所耗费的时间
//测试环境：Celeron 800MHz / 256M SDRAM
// Windows 2000 Professional SP2
// Microsoft Visual C++ 6.0 SP5
////////////////////////////////////////////////
以下是Timer1的运行结果，使用的是高精度的RDTSC指令
Lasting Time: 804586872
以下是Timer2的运行结果，使用的是最粗糙的timeGetTime API
Begin Time: 20254254
End Time: 20255255
Lasting Time: 1001
以下是Timer3的运行结果，使用的是QueryPerformanceCount API
Frequency: 3579545
Begin Time: 3804729124
End Time: 3808298836
Lasting Time: 3569712