Edit report at https://bugs.php.net/bug.php?id=64633&edit=1
ID: 64633
Comment by: martin dot hason at gmail dot com
Reported by: phpbugs at musiclogistics dot net
Summary: microtime regression - resolution reduced to 64
ticks per second
Status: Assigned
Type: Bug
Package: Date/time related
Operating System: Windows 7
PHP Version: 5.4.14
Assigned To: pajoye
Block user comment: N
Private report: N
New Comment:
The same problem occurs in PHP 5.5.1 too! Please fix this bug.
Previous Comments:
------------------------------------------------------------------------
[2013-06-16 04:02:52] yaro at opti dot su
The same problem occurs in PHP 5.4.15 too!
Why developers ignore such an important issue?
------------------------------------------------------------------------
[2013-04-12 14:22:32] phpbugs at musiclogistics dot net
@a...@php.net: You are right: While usleep() only works in 1/64 second
increments on my machine (640 loops of "usleep(1)" take about 10 seconds), this
is not related to PHP 5.4.14. It's the same on 5.4.13 and probably a limitation
of Windows' multitasking.
------------------------------------------------------------------------
[2013-04-12 11:29:36] paj...@php.net
We should use performance counters instead, which brings a much higher
precision
at less cost.
------------------------------------------------------------------------
[2013-04-12 11:25:47] a...@php.net
This is a tradeoff one has to make, precision vs. accuracy. That's very
depending on the hardware. While on one system using the performance timer it
would work as expected, on another it's still more accurate time with a very
variable precision. That's where you could see in your snippet currentTimeMs()
- $startTimeMs < 0. That is much more weird than possibly having a worse
resolution, say currentTimeMs() - $startTimeMs == 0.
Heres' an interesting reading about this
http://blogs.msdn.com/b/oldnewthing/archive/2005/09/02/459952.aspx . The goal
of the latest fix is to remove the random results. Also this will work in most
cases as normally a script doesn't consist on just two subsequent microtime
calls. Starting with win8 there is a much better API, but it of course doesn't
help here. I'm not sure it should be touched, will look how to improve it
without getting to the old erroneous behaviour. Maybe reimplement the
performance timer part and make an ini option to let user decide if the
performance timer should be used. As we really cannot foresee every hardware
bugs.
Btw. usleep() isn't affected by that, it uses the waitable timer which has a
better resolution.
------------------------------------------------------------------------
[2013-04-11 16:52:09] phpbugs at musiclogistics dot net
Description:
------------
Probably caused by recent patch for bug #64370:
Since v 5.4.14 microtime() only moves forward in 15,6 ms (1/64 sec) increments
on Win7. Same for CLI and Apache 2.2 SAPI.
Build: VC9 x86 Thread Safe (2013-Apr-10 22:55:28) from windows.php.net.
Behaviour normal after downgrade to 5.4.13.
This also breaks usleep() (only sleeping for multiples of 15,6 ms now) and
uniqid() (returning the same value for 15,6 ms with $more_entropy = false).
Test script:
---------------
for ($startTimeMs = currentTimeMs(), $i = 0; $i < 10000; $i++) {
//usleep(1);
echo (currentTimeMs() - $startTimeMs) . ' ';
}
function currentTimeMs() {
return round(microtime(true) * 1000000);
}
Expected result:
----------------
[what PHP 5.4.13 prints on the same machine:]
13 28 35 41 48 54 61 67 74 80 86 92 99 105 112 118 124 131 137 143 149 155 162
168 174 181 187 193 200 206 212 218 224 [...and so on]
Actual result:
--------------
0 0 0 0 0 0 0 0 0 [many more zeroes] 15600 15600 15600 15600 [...] 31200 31200
31200 31200 31200 [...] 46800 46800 46800 46800 46800 [...and so on]
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=64633&edit=1
