A lot of the comments here suggest adding in the following way: (float)$usec + (float)$secMake sure you have the float precision high enough as with the default precision of 12, you are only precise to the 0.01 seconds. Set this in you php.ini file. precision = 16

Rather than using the list() function, etc. I have found the following code to be a bit cleaner and simpler:<?php$theTime = array_sum( explode( ' ' , microtime() ) );echo $theTime;# Displays "1212018372.3366"?>

While doing some experiments on using microtime()'s output for an entropy generator I found that its microsecond value was always quantified to the nearest hundreds (i.e. the number ends with 00), which affected the randomness of the entropy generator. This output pattern was consistent on three separate machines, running OpenBSD, Mac OS X and Windows.

The solution was to instead use gettimeofday()'s output, as its usec value followed no quantifiable pattern on any of the three test platforms.

Of the methods I've seen here, and thought up myself, to convert microtime() output into a numerical value, the microtime_float() one shown in the documentation proper(using explode,list,float,+) is the slowest in terms of runtime.

I implemented the various methods, ran each in a tight loop 1,000,000 times, and compared runtimes (and output). I did this 10 times to make sure there wasn't a problem of other things putting a load spike on the server. I'll admit I didn't take into account martijn at vanderlee dot com's comments on testing accuracy, but as I figured the looping code etc would be the same, and this was only meant as a relative comparison, it should not be necessary.

The above method took on average 5.7151877 seconds, while a method using substr and simply adding strings with . took on average 3.0144226 seconds. rsalazar at innox dot com dot mx's method using preg_replace used on average 4.1819633 seconds. This shows that there are indeed differences, but for normal use noone is going to notice it.

Note that the substr method mentioned isn't quite the one given anonymously below, but one I made based on it:<?php$time=microtime();$timeval=substr($time,11).substr($time,1,9);?>

Also worth noting is that the microtime_float() method gets faster, and no less accurate, if the (float) conversions are taken out and the variables are simply added together.

Any of the methods that used + or array_sum ended up rounding the result to 2 digits after the decimal point, while (most of) the ones using preg_replace or substr and . kept all the digits.

For accurate timing, since floating-point arithmetic would lose precision, I stored microtime results as-is and calculated time difference with this function:<?phpfunction microtime_used($before,$after) { return (substr($after,11)-substr($before,11)) +(substr($after,0,9)-substr($before,0,9));}?>

I wanted to find out whether echo would be quicker in small chunks or one large chunk to test the theory mentioned in the previous post. The following experiment shows that there is no significant performance difference, in terms of execution time elapsed, between the two methods of using echo. I ran two test cases, one with a string that is 100000 bytes long and another with a string length of 1000000. The source code follows below.

Note that the timestamp returned is "with microseconds", not "in microseconds". This is especially good to know if you pass 'true' as the parameter and then calculate the difference between two float values -- the result is already in seconds; it doesn't need to be divided by a million.

However it is true that result depends of gettimeofday() call. ([jamie at bishopston dot net] wrote this & I can confirm)If system time change, result of this function can be unpredictable (much greater or less than zero).

Want to make sure your script doesn't time out on large updates? Say you're doing a poor mans cron job or working with large amounts of data in loop and the user begins to hang too long. Instead of them giving up and leaving you can break the loop when it reaches a set time and still display data.

It would be useful if they add another parameter for precision in this function or at least another boolean that will not include the hidden precision.You can read more about the hidden precision in http://php.net/float

/** * This function return the time the code use to process * @param $precision the precision wanted, with const. second, millisecond and microsecond available (default PRECISION_SECOND) * @param $floatingPrecision the number of numbers after the floating point (default 0) * @param $showUnit precise if the unit should be returned (default true) * @return the render time in the precision asked. Note that the precision is ±0.5 the precision (eq. 5s is at least 4.5s and at most 5.5s) <br/> * The code have an error about 2 or 3µs (time to execute the end function) */public function getRenderTime($precision = self::PRECISION_SECOND, $floatingPrecision = 0, $showUnit = true){

microtime()'s string value is in the format "0.dddddd00 ddddd...". That is, there's room for 10-ns precision that isn't being used, and the "msec" value is in decimal, not a literal number of microseconds (and *especially* not milliseconds, which is what msec usually stands for) as the documentation might imply.

Interesting quirk (tested in PHP 5.0.3): You can get very wacky results from microtime when it is called in the destructor of an object at the end of a script. These times vary enormously and can be in the *past*, when compared to microtime calls in the body of the script.

As a case example, I played with a timer object that measured microtime when it was created at the start of the script, and measured microtime again at the end of the script using __destruct(); and then printed the total execution time (end time - start time) at the bottom of the page. On short scripts, this would often give a negative time!

This quirk does not appear if microtime is measured with an automatic shutdown function (using <?PHP register_shutdown_function('myfunc') ?>. Incidentally, the automatic shutdown functions are called after output buffers are flushed but before object destructors are called.

But note that the default 'precision' setting of PHP* - which is used when a float is converted to a stringy format by echo()ing, casting or json_encode()ing etc - is not enough to hold the six digit accuracy of microtime(true).

Out of the box, microtime(true) will echo something like:

1377611450.1234

Which is obviously less than microsecond accuracy. You'll probably want to bump the 'precision' setting up to 16 which will echo something like:

1377611450.123456

*Internally* it will be accurate to the six digits even with the default 'precision', but a lot of things (ie. NoSQL databases) are moving to all-text representations these days so it becomes a bit more important.