Tom Lane wrote:
>"Ken Egervari" <ken@upfactor.com> writes:
>
>
>>Okay, here is the explain analyze I managed to get from work.
>>
>>
>
>What platform is this on? It seems very strange/fishy that all the
>actual-time values are exact integral milliseconds.
>
>
>
I always get round milliseconds on running. In fact, I think I've seen
cases where it was actually rounding to 15/16ms. Which is the resolution
of the "clock()" call (IIRC).
This is the function I have for returning time better than clock(), but
it looks like it is still stuck no better than 1ms.
/*
* MSVC has a function called _ftime64, which is in
* "sys/timeb.h", which should be accurate to milliseconds
*/
#include <sys/types.h>
#include <sys/timeb.h>
double mf::getTime()
{
struct __timeb64 timeNow;
_ftime64(&timeNow);
return timeNow.time + timeNow.millitm / 1000.0;
}
I did, however, find this page:
http://www.wideman-one.com/gw/tech/dataacq/wintiming.htm
Which talks about the high performance counter, which is supposed to be
able to get better than 1us resolution.
GetSystemTimes() returns the idle/kernel/user times, and seems to have a
resolution of about 100ns (.1us) GetLocalTime()/GetSystemTime() only has
a resolution of milliseconds.
In my simple test, I was actually getting timings with a resolution of
.3us for the QueryPerformanceCounter(). That was the overhead of just
the call, since it was called either in a bare loop, or just one after
the other.
So probably we just need to switch to QueryPerformanceCounter()
[/Frequency].
John
=:->
