我想使用 Boost 获得毫秒精度的时间。（精度不需要毫秒级，接近即可。）
参考Local time with milliseconds等，表示应该使用微秒时钟：
boost::posix_time::microsec_clock::local_time();
根据我的经验，使用标准的、低影响的系统调用（即::GetTicks()在 Windows 上）不可能获得精确到微秒的时间（假设有类似的精度）。相反，需要发出 CPU 密集型调用以提高超过毫秒（到微秒）的精度。
正如我所提到的，我不需要微秒级的精度 - 只是有点接近毫秒级的精度。但是，Boost.Date_Time 不提供任何“millisec_clock” - 它提供second_clock，并且下一个渐变是microsec_clock，中间没有“millisec_clock”。
microsec_clock如前所述，如果我使用MILLIseconds 来获取 MILLIseconds，我会受到 CPU 密集型调用的打击吗？
我使用 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）。
我希望这是您正在寻找的答案类型。
根据相关文档：
在大多数 Win32 平台上，它是使用 ftime 实现的。Win32 系统通常无法通过此 API 实现微秒级分辨率。如果更高的分辨率对您的应用程序至关重要，请测试您的平台以查看达到的分辨率。
ftime 似乎不是一个过于繁重的功能（这是一个关于它如何工作的问题），但我想这取决于你对 CPU 密集型的想法。