现在我正在加载一个文件，然后使用gettimeofday并使用tv_usec跟踪CPU时间
我的结果有所不同，我得到250到280s但有时300或500。我写了睡眠，睡觉（0）和（1）没有成功。时间仍然差异很大。我认为睡眠（1）（linux中的秒数，而不是Windows中的睡眠时间）会解决它。如何以更一致的方式跟踪时间进行测试？也许我应该等到我开始测量之前有更大的测试数据和更复杂的代码？
答案 0 :(得分：4)
目前推荐的Linux（以及一般POSIX）上高rez时间的接口是clock_gettime。请参见手册页。
clock_gettime(CLOCK_REALTIME, struct timespec *tp) // for wall-clock time
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, struct timespec *tp) // for CPU time
但请阅读手册页。请注意，您需要与-lrt链接，因为POSIX这样说，我想。也许为了避免在-lc中出现符号冲突，对于定义了自己的clock_gettime的旧程序？但是动态库使用弱符号......
最好的睡眠功能是nanosleep。它不会乱丢信号或像usleep这样的垃圾。它定义为只是睡觉，没有任何其他副作用。并且它会告诉您是否早早醒来（例如从信号中醒来），因此您不一定要调用另一个时间函数。
无论如何，你将很难测试一个涉及系统调用的短信代表。变异的机会很多。例如调度程序可能会决定其他一些工作需要做（如果您的进程刚刚启动，则不太可能;您还不会用完您的时间片）。 CPU缓存（L2和TLB）很容易实现。
如果您有一个多核机器和一个用于优化代码的单线程基准测试，您可以将其实时优先级固定到您的一个核心。确保选择不处理中断的核心，否则键盘（以及其他所有内容）将被锁定，直到完成为止。使用taskset（用于固定到一个CPU）和chrt（用于设置实时prio）。 看到我发送给gmp-devel的这封邮件： http://gmplib.org/list-archives/gmp-devel/2008-March/000789.html
哦，是的，为了最准确的时间，你可以自己使用rdtsc（在x86 / amd64上）。如果您没有任何其他系统调用，那么这不是一个坏主意。抓住一个基准测试框架来实现你的功能。 GMP有一个相当不错的。但是，对于不在GMP中并且称为mpn_whatever的基准功能，它可能没有很好地设置。我不记得了，值得一看。
答案 1 :(得分：2)
您是否尝试测量加载文件所需的时间？通常，如果你的性能测试已经很快（亚秒），那么你会想要重复相同的代码很多次（比如一千或一百万），整个时间，然后将总时间除以迭代次数。
话虽如此，我不太确定你在使用sleep（）。你能发布一个你打算做什么的例子吗？
答案 2 :(得分：1)
我建议将该代码放在for循环中。运行1000或10000次迭代。如果你只做了一些指示，那就有问题了，但它应该会有所帮助。
更大的数据集当然也有帮助。
睡眠将从cpu中取消你的线程。它没有精确计算时间。