Question

我正在做一些大的时间戳列表迭代：将它们放在tables with date-ranges中，并按范围对它们进行分组。为了做到这一点，我发现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

你为什么担心它的表现？你有证据表明你的系统正在放慢速度吗？如果没有，请不要因为不必要的原因而过度复杂化解决方案。请记住premature optimization is the root of all evil。编写有意义的可读代码，只有在您知道它将成为问题时才进行优化...

但要考虑的其他事情是它也编译了C代码，所以它应该非常有效。您可能能够在PHP中构建代码的子集并使其更快，但这将是一项艰巨的工作（由于PHP代码中涉及的所有开销）。

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

Answer 2

回答这个问题，最后：

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

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

Answer 3

非常有趣的问题。我想说你能解决这个问题的唯一方法就是建立自己的性能测试。观察脚本开头和结尾的microtime（）值，以确定性能。使用一种方法通过循环运行一个荒谬的数值，然后使用另一种方法。比较时间。

Answer 4

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

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

顺便说一下，如果你有很好的分析工具，真棒，但即使你不比较时间戳也应该给你一个粗略的想法。

PHP strtotime（）的性能如何？

4 个答案: