Date: 04/01/99
- Next message: mf <email protected>: "[PHP-DEV] Bug #1282: strtok ignores zero's"
- Previous message: Bug Database: "[PHP-DEV] Bug #1121 Updated: Show_source produces odd looking output after upgrading to 3.0.6"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
From: markus.laire <email protected>
Operating system: Win95
PHP version: 3.0.6
PHP Bug Type: Misbehaving function
Bug description: microtime() doesn't work in Win32-version
I just copied Win32-version of PHP 3.0.6 files to the directory without any other configurations.
Following is message I send to the php3-list about
"[PHP3] Differences in win32 and linux versions"
> start = 135.87952200 922643904 - end = 136.02899400 922643904
>
> Does this mean that it only took 136.03 - 135.88 = .15 milliseconds to
> execute the db stuff? I am not quit sure what the "msec" part of the
> microtime() function represents.
That means it took _about_ (nowhere near exactly - see below)
0.15 seconds to execute that.
I tested differences in win32 and linux by running following script
with win32-version of PHP in my Win95-computer and also in my
homepage at linux-server.
<?php
for ($x = 0; $x < 10000; $x++) {
usleep(1000); // sleep 1/1000 seconds = 1 millisecond
// so that this script won't execute too fast
echo microtime(), ' ', time(), ' ', date("U H:i:s"), "\n<BR>";
}
?>
With Linux, script printed
0.5xxxxxxx 922695800 922695800 922695800 11:23:20
0.5xxxxxxx 922695800 922695800 922695800 11:23:20
0.5xxxxxxx 922695800 922695800 922695800 11:23:20
..
0.9xxxxxxx 922695800 922695800 922695800 11:23:20
0.0xxxxxxx 922695801 922695801 922695801 11:23:21
..
0.9xxxxxxx 922695801 922695801 922695801 11:23:21
0.0xxxxxxx 922695802 922695802 922695802 11:23:22
..
This is just what I expected script should print.
So, msec part is always between 0.0 and 1.0, and you can get real
time simply by calculating $msec_part + $sec_part
But, when run with Win32, this isn't so simple:
With Win32, script printed:
216.5xxxxxxx 922695800 922695800 922695800 11:23:20
216.5xxxxxxx 922695800 922695800 922695800 11:23:20
216.5xxxxxxx 922695800 922695800 922695800 11:23:20
..
216.94920900 922695800 922695800 922695800 11:23:20
216.95155400 922695801 922695801 922695801 11:23:21
..
216.99951800 922695801 922695801 922695801 11:23:21
217.00153500 922695801 922695801 922695801 11:23:21
..
217.94497400 922695801 922695801 922695801 11:23:21
217.94760700 922695802 922695802 922695802 11:23:22
..
217.99750800 922695802 922695802 922695802 11:23:22
218.00003600 922695802 922695802 922695802 11:23:22
..
First, msec part isn't between 0.0 and 1.0 and when you use it,
you must first discard integer part of it and only take fraction part
which is between 0.0 and 1.0.
Much more important thing is, that msec part and sec part are
NOT synchronized and so you can't get real time by calculating
$fraction_of_msec_part + $sec_part
This is about the real time, but not exactly.
This script run about 23 seconds and below are start and end
times:
216.94920900 922695800 922695800 922695800 11:23:20
216.95155400 922695801 922695801 922695801 11:23:21 <- start
..
237.97241700 922695822 922695822 922695822 11:23:42
237.97522000 922695822 922695823 922695823 11:23:43 <- end
sec part difference: end-start = 43-21 = 22
msec part difference: end-start = 237.97522000-216.95155400 = 21.023666
accuracy is about 22sec/10000 = 0.0022secs
21.02 / 22 = 95.5%
So, when sec-part goes up by one, msec-part goes up - not by one
- but by about 0.955. These two times increases with diffferent
speed and because that, they aren't synchronized.
-- PHP Development Mailing List http://www.php.net/ To unsubscribe send an empty message to php-dev-unsubscribe <email protected> For help: php-dev-help <email protected>
- Next message: mf <email protected>: "[PHP-DEV] Bug #1282: strtok ignores zero's"
- Previous message: Bug Database: "[PHP-DEV] Bug #1121 Updated: Show_source produces odd looking output after upgrading to 3.0.6"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

