是boost :: posix_time :: microsec_clock CPU密集型？

Question

我想用毫秒精度获得使用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来获得MILLIseconds，我会被CPU密集型呼叫打中吗？

Answer 1

按照Relevant documentation：

在大多数Win32平台上它使用FTIME实现。通过这个API，Win32系统通常不会达到微秒级的分辨率。如果更高的分辨率对您的应用至关重要，请测试您的平台以查看实现的分辨率

ftime似乎不是一个过于沉重的功能（here is a question about how it works），但我想这取决于您的CPU密集型的想法。

Answer 2

我也用来衡量一个函数内部花费的时间，使用boost :: date_time的对象辅助对象和especifically我用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）。

我希望这是答案的你要找的类型。