Tom Lane wrote:

"Ken Egervari" <[EMAIL PROTECTED]> 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;
   return timeNow.time + timeNow.millitm / 1000.0;

I did, however, find this page:

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].


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to