|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[1999-09-21 04:24 UTC] sas at cvs dot php dot net
|
|||||||||||||||||||||||||||
Copyright © 2001-2026 The PHP GroupAll rights reserved. |
Last updated: Fri Jul 10 06:00:02 2026 UTC |
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.