我想使用Boost以毫秒精度获得时间。 （准确度不需要是毫秒，只需要接近。）
参考Local time with milliseconds和其他人，指出应该使用微秒钟：
boost::posix_time::microsec_clock::local_time();
根据我的经验，使用标准的低影响系统调用（即Windows上的::GetTicks()），不可能获得精确到微秒（假设有一些类似的准确度）的时间。相反，需要发出CPU密集型调用以提高精度，超过毫秒（以微秒为单位）。
正如我所提到的，我不需要微秒精度 - 只是接近毫秒精度。但是，Boost.Date_Time不提供任何“millisec_clock” - 它提供second_clock，下一个渐变为microsec_clock，中间没有“millisec_clock”。
如果我使用microsec_clock来获取MILLI秒，我是否会受到CPU密集型呼叫？
答案 0 :(得分：5)
我做了一个辅助对象用于测量函数内部的时间，使用boost :: date_time对象，特别是我使用了microsec_clock :: local_time（）。
我正在使用这个对象测量几百万个不同函数的快速调用（压力测试用例），突然我开始注意到我无法解释我的进程的大量执行时间。经过一些实验，我删除了大部分这些计数器，我的代码总执行时间从大约23分钟到大约12分钟（大约50％!!）
所以，根据我的经验回答你的问题，microsec_clock :: local_time（）是昂贵的。
看到这个后，我使用microsec_clock :: universal_time（）而不是microsec_clock :: local_time（）进行了测试，这绝对是我运行时间的改进。它还增加了大约3分钟，但好于10分钟：P。考虑一下，我想问题是local_time（）抵消时间值来考虑时区，在我的情况下不需要（因为我只需要时间上的差异）。我仍然需要进行测试以检查其他方法是否更快（例如clock_gettime）。
我希望这是您正在寻找的答案类型。
答案 1 :(得分：1)
在大多数Win32平台上，它是使用ftime实现的。 Win32系统通常不能通过此API实现微秒级分辨率。如果更高的分辨率对您的应用程序至关重要，请测试您的平台以查看已达到的分辨率。
ftime似乎不是一个过于繁重的函数（here is a question about how it works），但我想这取决于你对CPU密集型的看法。