【问题标题】:Fastest way to get approximate time difference获得近似时差的最快方法
【发布时间】:2018-10-09 10:54:10
【问题描述】:

我有一个将当前时间作为字符串返回的方法。虽然这种方法每秒被调用数百万次,因此我以多种方式优化了这种方法(为时间字符串静态分配缓冲区等)。

对于这个应用程序,近似时间是完全可以的。例如,我使用 10 毫秒的分辨率。在此时间内返回相同的时间字符串。

虽然在分析代码时,clock() 调用会消耗大量时间。

我还有哪些其他更快的选择来近似以毫秒分辨率的时间差?

【问题讨论】:

  • 您真的需要将时间作为字符串每秒数百万次吗?听起来这里有一些很奇怪的设计选择。
  • 你为什么要将时间转换成每秒几百万次的字符串?
  • 这个问题是有效的,尽管它确实是这样。该代码是 SQL 引擎的 datetime 方法的一部分。选择代码的不是我,而是客户通常在用户可分配的 SQL 中使用日期时间比较,因此我需要对其进行优化。此外,使用静态缓冲区已经优化了字符串的使用。时间测量现在占用了大量的 CPU。
  • 如果您使用 10 毫秒的分辨率,那么无论调用该方法多少次,您每秒只更新字符串 100 次。所以不清楚为什么clock() 调用会消耗这么多时间。
  • 该方法每秒调用 100 万次,clock() 也被调用 100 万次以检查时差。换句话说:字符串被优化为每秒仅更新 100 次,并且还被优化为使用静态分配的内存。该方法返回 100 万次,但只返回 100 次不同的字符串。确实是剩余的 1M 调用 clock() 需要很多时间。其他一切都经过优化。

标签: c performance


【解决方案1】:

回答我自己的问题:解决方案是限制对clock() 的调用,或任何时间函数。整个测试用例的总执行时间现在快了 22 倍。

我想我可以在对其进行广泛分析后给出一般性建议:如果您可以忍受较低的时间分辨率,并且您确实需要优化代码以提高速度,请将问题更改为使用单个全局计时器并避免代价高昂每次运行的时间比较。

我现在有一个简单的线程,休眠到所需的解析时间,并在每个循环上更新一个原子 int 代码变量。 在我需要优化的函数中,我只需比较两个整数(最后一个刻度和当前刻度)。如果不相等,是时候更新了。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-07-19
    • 2012-11-13
    • 1970-01-01
    • 2011-07-24
    • 2015-06-25
    • 2013-02-25
    相关资源
    最近更新 更多