PHP strtotime() 的性能如何？

Question

我正在进行一些大型时间戳列表迭代：将它们放入 带有日期范围的表格，并按范围对它们进行分组。 为了做到这一点，我发现 strtotime() 是一个非常有用的函数，但我担心它的性能。

例如，一个循环遍历周列表（例如，第 49 周到第 05 周）的函数，并且必须确定该周的开始和该周结束时的时间戳。一种有用的方法是：

foreach ($this->weeks($first, $amount) as $starts_at) {
  $ends_at = strtotime('+1 week', $starts_at);
  $groups[$week_key] = $this->slice($timestamps, $starts_at, $ends_at);
}

//$this->weeks returns a list of timestamps at which each week starts.
//$this->slice is a simple helper that returns only the timestamps within a range, from a list of timestamps. 

我可以找出一周开始和结束之间的秒数，而不是 strtotime()，99% 的时间是24 * 60 * 60 * 7。但在这些存在 DST 切换的罕见情况下，24 应该是 23 或 25。解决这个问题的代码可能会比 strtotime() 慢很多，不是吗？

我对年、月（月，非常不一致！）、日和小时的范围使用相同的模式。只有几个小时我才会怀疑简单地将 3600 添加到时间戳会更快。

还有其他问题吗？是否有方法（不依赖于 PHP5.3！）为一致、DST 和闰年安全日期范围提供更好的路线？

Answer 1

非常有趣的问题。我想说，真正解决这个问题的唯一方法是设置自己的性能测试。观察脚本开头和结尾处 microtime() 的值，以确定性能。使用一种方法，然后使用另一种方法，通过循环运行大量的值。比较次数。

Answer 2

您为什么担心它的表现？您有证据表明它正在减慢您的系统吗？如果不是，请不要出于不必要的原因尝试使解决方案过于复杂。请记住，过早的优化是万恶之源。编写有意义的可读代码，并且仅在您知道这将是一个问题时才进行优化...

但需要考虑的其他事情是它也是编译的 C 代码，因此它的功能应该非常高效。您也许能够在 PHP 领域构建代码的子集并使其更快，但这将是一项困难的工作（由于 PHP 代码涉及所有开销）。

就像我之前说的，使用它直到证明它是一个问题，然后解决该问题。不要忘记根据您的需要重写它也不是免费的。这需要时间并引入错误。如果增益很小（这意味着它一开始就不是性能问题），那么值得吗？因此，除非您知道这是一个问题，否则不要费心尝试微观优化......

Answer 3

我知道这可能不是您正在寻找的答案，但您最好的选择是分析它并考虑真实用例。

我的直觉是，正如您所想，strtotime 会更慢。但即使慢了 3 倍，这也只有在上下文中才有意义。也许您的例程（使用真实数据）使用 strtotime 需要 60 毫秒，因此在大多数情况下，您只会节省 40 毫秒（这些数字完全是我编造的，但您明白了）。因此，您可能会发现优化这一点并不会真正带来回报（考虑到您正在向更多潜在错误开放代码，并且您必须投入更多时间来解决问题）。

顺便说一句，如果您有良好的分析工具，那就太棒了，但即使您不比较时间戳也应该给您一个粗略的了解。

Answer 4

最后要回答这个问题：

基于许多这样的基准： https://en.code-bude.net/2013/12/19/benchmark-strtotime-vs-datetime-vs-gettimestamp-in-php/

我们可以看到strtotime()比我们想象的更有效。
所以，是的，要将字符串转换为时间戳，strtotime 函数具有相当好的性能。