Tom Lane wrote:
"Ken Egervari" <[EMAIL PROTECTED]> writes: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).
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.
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 =:->
signature.asc
Description: OpenPGP digital signature
