我想使用Boost获得毫秒精度的时间。(准确度不需要是毫秒，只要接近即可。)
参考以毫秒为单位的本地时间和其他时间，表明应使用微秒时钟：
boost::posix_time::microsec_clock::local_time();
根据我的经验，使用标准的低影响系统调用(即Windows上的::GetTicks())不可能获得微秒精度的时间(假设具有类似的精度)。相反，需要发出CPU密集型调用，以将精度提高到毫秒(微秒)以上。
正如我所提到的，我不需要微秒的精度——只需要稍微接近毫秒的精度。但是，Boost.Date_Time不提供任何"毫秒锁"-它提供second_clock，下一个渐变为microsec_clock，中间没有"毫秒锁"。
如前所述，如果我使用microsec_clock来获得毫秒，我会被CPU密集型调用击中吗？
我用boost:：date_time对象做了一个助手对象，用来测量函数内部花费的时间，特别是我用了microsc_clock:：local_time()。
我使用这个对象来测量对不同函数的数百万次快速调用(一个压力测试用例)，突然我开始注意到我无法解释流程的大部分执行时间。经过一些实验，我删除了大部分计数器，代码的总执行时间从大约23分钟增加到大约12分钟(大约50%！！)
因此，根据我的经验来回答您的问题，microsec_clock:：local_time()非常昂贵。
看到这一点后，我用microsec_clock:：universal_time()代替了microsec_cclock:：local_time(。它仍然增加了大约3分钟，但比10分钟要好：P。仔细想想，我想问题是local_time()偏移了时间值来考虑时区，在我的情况下，这是不需要的(因为我只需要时间上的差异)。我仍然需要做一个测试来检查其他方法是否更快(比如clock_gettime)。
我希望这是你想要的答案。
根据相关文档：
在大多数Win32平台上，它是使用ftime实现的。Win32系统通常无法通过此API实现微秒级的分辨率。如果更高的分辨率对您的应用程序至关重要，请测试您的平台以查看实现的分辨率。
ftime似乎不是一个过于沉重的函数(这里有一个关于它如何工作的问题)，但我想这取决于你对CPU密集型的看法。