3

我正在做一些大的时间戳列表迭代：将它们放在带有 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 和闰年的安全日期范围提供更好的路线？

4

4 回答 4

12

你为什么担心它的性能？您是否有证据表明它正在减慢您的系统速度？如果没有，请不要因为不必要的原因使解决方案过于复杂。记住这一点premature optimization is the root of all evil。编写有意义的可读代码，并且只有在您知道这将是一个问题时才进行优化......

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

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

于 2010-10-12T13:13:39.063 回答
1

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

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

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

于 2010-10-11T15:28:52.377 回答
1

为了回答这个问题，最后：

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

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

于 2017-11-17T17:06:36.047 回答
0

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

于 2010-10-11T15:26:45.143 回答