Re: explain analyze timings

On Sun, 2005-03-20 at 14:42 +0100, Magnus Hagander wrote:

There is. I beleive QueryPerformanceCounter has sub-mirosecond
resolution.

Can we just replace gettimeofday() with a version that's basically:

No, because it's also used for actual time-of-day calls. It'd be
necessary to hack executor/instrument.c in particular.

Here's a patch that does just this.

On my system, the counter resolution is 3192090000 ticks per second
(Intel Xeon CPU). On a AMD Athlon XP system, it's 3579545 ticks per
second (a lot less, but still way way way better than gettimeofday has
on win32).

Is this just a Win32 hack?

I've been looking for a sub-millisecond counter on other OS for a while
now...anybody know of any port specific counters elsewhere?

Thanks,

Best Regards, Simon Riggs

Simon Riggs wrote:

On Sun, 2005-03-20 at 14:42 +0100, Magnus Hagander wrote:

There is. I beleive QueryPerformanceCounter has sub-mirosecond
resolution.

Can we just replace gettimeofday() with a version that's basically:

No, because it's also used for actual time-of-day calls. It'd be
necessary to hack executor/instrument.c in particular.

Here's a patch that does just this.

On my system, the counter resolution is 3192090000 ticks per second
(Intel Xeon CPU). On a AMD Athlon XP system, it's 3579545 ticks per
second (a lot less, but still way way way better than gettimeofday has
on win32).

Is this just a Win32 hack?

I've been looking for a sub-millisecond counter on other OS for a while
now...anybody know of any port specific counters elsewhere?

Thanks,

gettimeofday has microsecond resolution. And on most platforms you
actually do get good resolution from it.
QueryPerformanceCounter is win32 only, and it has variable resolution,
as determined by QueryPerformanceFrequency. (obviously as above the Xeon
claims 3B/s while Athlon is only 3.5M/s)
But that is just the finest resolution they can show, you still need to
test to see what the resolution they can give you.
On my dual Xeon I get Freq=2399360000 =2.4B/s In testing, the call
overhead seems to be about .35us, so the resolution is just < 1us.

Best Regards, Simon Riggs

John
=:->

"Magnus Hagander" <mha@sollentuna.net> writes:

Here's a patch that does just this.

This seems about the ugliest and most intrusive way you could have
done it :-(. A judicious typedef and macro or two could eliminate
most of the #ifdefs and code duplication, thereby preserving
readability...

regards, tom lane

Here's a patch that does just this.

This seems about the ugliest and most intrusive way you could have
done it :-(. A judicious typedef and macro or two could eliminate
most of the #ifdefs and code duplication, thereby preserving
readability...

Well, I certainly can't argue with that, now that you mention it ;-)
Here is a second attempt, hope it's closer to what you expected.

I still left two #ifdefs in there, for the addition and subtraction of
timeval:s specifically. They could be made functions/macros too, just
not sure if it's worth it.

Tested on win32 and linux (now that it changes non-win32 specific code
as well).

//Magnus

"Magnus Hagander" <mha@sollentuna.net> writes:

Here is a second attempt, hope it's closer to what you expected.

Better --- patch applied with some minor editorialization.

I still left two #ifdefs in there, for the addition and subtraction of
timeval:s specifically. They could be made functions/macros too, just
not sure if it's worth it.

Probably not. What bothers me more is the unconditional use of a
static inline function; but IIRC we are only supporting gcc-based builds
on Windows, so that probably isn't worth fixing either.

regards, tom lane