Thread: Re: [pgsql-hackers-win32] Help with tuning this query (with explain analyze finally)

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Monday, March 07, 2005 10:39 AM
> To: John A Meinel
> Cc: Magnus Hagander; Ken Egervari; pgsql-performance@postgresql.org;
> pgsql-hackers-win32@postgresql.org
> Subject: Re: [pgsql-hackers-win32] [PERFORM] Help with tuning
> this query
> (with explain analyze finally)
>
> [...]
> The EXPLAIN ANALYZE instrumentation code will really be happier with a
> straight time-since-bootup counter; by using gettimeofday, it is
> vulnerable to giving wrong answers if someone changes the date setting
> while the EXPLAIN is running.  But there is (AFAIK) no such call among
> the portable Unix syscalls.  It seems reasonable to me to #ifdef that
> code to make use of QueryPerformanceCounter on Windows.  This does not
> mean we want to alter the behavior of gettimeofday() where it's being
> used to find out the time of day.

There is always clock().  It's mandated by ANSI C, but my docs say
that POSIX requires CLOCKS_PER_SEC == 1000000 regardless of actual
timer resolution, which seems a little brain-dead to me.

__
David B. Held
Software Engineer/Array Services Group
200 14th Ave. East,  Sartell, MN 56377
320.534.3637 320.253.7800 800.752.8129

Dave Held wrote:

>There is always clock().  It's mandated by ANSI C, but my docs say
>that POSIX requires CLOCKS_PER_SEC == 1000000 regardless of actual
>timer resolution, which seems a little brain-dead to me.
>
>__
>David B. Held
>
>

My experience with clock() on win32 is that CLOCKS_PER_SEC was 1000, and
it had a resolution of 55clocks / s. When I just did this:

int main(int argc, char **argv)
{
    int start = clock();
    int now = start;
    cout << "Clock: " << CLOCKS_PER_SEC << endl;
    for(int i = 0; i < 10; ++i) {
        while(now == clock()) {
            // Do nothing
        }
        now = clock();
        cout << now-start << "\t" << (now - start) / (double)
CLOCKS_PER_SEC << endl;
    }
}

I got:
Clock: 1000
16      0.016
31      0.031
47      0.047
62      0.062
78      0.078
93      0.093
109     0.109
125     0.125
141     0.141
156     0.156

Which is about 1/0.016 = 62.5 clocks per second.
I'm pretty sure this is slightly worse than what we want. :)
It might be better on other platforms, but on win32 clock() is most
definitely *not* what you want.
John
=:->

John A Meinel <john@arbash-meinel.com> writes:
> Dave Held wrote:
>> There is always clock().

> My experience with clock() on win32 is that CLOCKS_PER_SEC was 1000, and
> it had a resolution of 55clocks / s. When I just did this:

The other problem is it measures process CPU time, not elapsed time
which is probably more significant for our purposes.

Which brings up a question: just what does QueryPerformanceCounter
measure?

            regards, tom lane

Tom Lane wrote:

>John A Meinel <john@arbash-meinel.com> writes:
>
>
>>Dave Held wrote:
>>
>>
>>>There is always clock().
>>>
>>>
>
>
>
>>My experience with clock() on win32 is that CLOCKS_PER_SEC was 1000, and
>>it had a resolution of 55clocks / s. When I just did this:
>>
>>
>
>The other problem is it measures process CPU time, not elapsed time
>which is probably more significant for our purposes.
>
>Which brings up a question: just what does QueryPerformanceCounter
>measure?
>
>            regards, tom lane
>
>
clock() according to the Visual Studio Help measures wall clock time.
But you're right, POSIX says it is approximation of processor time.

The docs don't say specifically what QueryPerformanceCounter() measures,
but states

> The *QueryPerformanceCounter* function retrieves the current value of
> the high-resolution performance counter.
>
It also states:

>
>         Remarks
>
> On a multiprocessor machine, it should not matter which processor is
> called. However, you can get different results on different processors
> due to bugs in the BIOS or the HAL. To specify processor affinity for
> a thread, use the *SetThreadAffinityMask* function.
>

So it sounds like it is actually querying some counter independent of
processing.

In fact, there is also this statement:

> *QueryPerformanceFrequency*
>
> The QueryPerformanceFrequency function retrieves the frequency of the
> high-resolution performance counter, if one exists. The frequency
> cannot change while the system is running.
>
If that is accurate, it would make QueryPerformanceCounter independent
of things like speed stepping, etc. So again, it sounds independent of
processing.

John
=:->