> Note, though, that microtime() is technologically obsolete.  with > 1
> GHz CPUs hitting the commodity market, we really should rework all the
> internal kernel APIs to use nanoseconds rather than microseconds.  For
> arches which don't (yet) have sub-microsecond resolution, just
> fake nanosecond times as (microtime * 1000).

Dangerous, it starts getting possible for nanosecond counts to
wrap 64 bit integers. 1 sec ~= 2^30 nanoseconds, so that would be
about 1000 years - ok until you start summing times across the
processes on a 1000+ cpu system, or want to keep time since
a sensible epoch.

If you are actually trying to measure the execution time of
short code fragments (as opposed to process execution times)
the raw counts from the fastest counter you have are
probably best - without any attenpt to scale them to match
reality.

	David

-- 
David Laight: david@l8s.co.uk