Re: [Windows,PATCH] Use faster, higher precision timer API

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: [Windows,PATCH] Use faster, higher precision timer API
Дата
Msg-id CAApHDvqChN0gwy90Czz0dOXXpVCX2+YbkbefuNS+kyPOMdKXdQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [Windows,PATCH] Use faster, higher precision timer API  (Craig Ringer <craig@2ndquadrant.com>)
Ответы Re: [Windows,PATCH] Use faster, higher precision timer API
Список pgsql-hackers
Дерево обсуждения
On Fri, Oct 10, 2014 at 10:08 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
On 09/17/2014 08:27 PM, Craig Ringer wrote:
> Hi all
>
> Attached is a patch to switch 9.5 over to using the
> GetSystemTimeAsFileTime call instead of separate GetSystemTime and
> SystemTimeToFileTime calls.

Following on from my prior patch that switches to using
GetSystemTimeAsFileTime, I now attach a two-patch series that also adds
support for GetFileTimePreciseAsFileTime where it is available.


Hi Craig,

I was just having a quick look at this with the view of testing it on a windows 8 machine.

Here's a couple of things I've noticed:

+ pg_get_system_time = (PgGetSystemTimeFn) GetProcAddress(
+ GetModuleHandle(TEXT("kernel32.dll")),
+ "GetSystemRimePreciseAsFileTime");


"Rime", not doubt is meant to be "Time".

Same here:

+ elog(DEBUG1, "GetProcAddress(\"GetSystemRimePreciseAsFileTime\") on kernel32.dll failed with error code %d not expected ERROR_PROC_NOT_FOUND(127)", errcode);

But I don't think you'll be able to elog quite that early.  I tested by getting rid of the if (errcode != ERROR_PROC_NOT_FOUND) test and I get:

D:\Postgres\install\bin>postgres -D ..\data
error occurred at src\port\gettimeofday.c:87 before error message processing is available

Perhaps we needn't bother with this debug message? Either that you'll probably need to cache the error code and do something when the logger is initialised. 

Also, just for testing the resolution of the 2 functions, I added some code into PostgreSQL's gettimeofday()

do{
(*pg_get_system_time)(&ft2);
}while ((file_time.dwLowDateTime - ft2.dwLowDateTime) == 0);

#ifndef FRONTEND
elog(NOTICE, "%d",  ft2.dwLowDateTime - file_time.dwLowDateTime);
if (pg_get_system_time == &GetSystemTimeAsFileTime)
elog(NOTICE, "GetSystemTimeAsFileTime");
else
elog(NOTICE, "GetSystemTimePreciseAsFileTime");
#endif

return 0;


I see:
test=# select current_timestamp;
NOTICE:  4
NOTICE:  GetSystemTimePreciseAsFileTime

Which indicates that this is quite a precise timer.

Whereas if I add a quick hack into init_win32_gettimeofday() so that it always chooses GetSystemTimeAsFileTime() I see:

test=# select current_timestamp;
NOTICE:  9953
NOTICE:  GetSystemTimeAsFileTime


Also, I've attached gettimeofday.c, which is a small test programme which just makes 10 million calls to each function, in order to find out which one of the 3 method performs best. Here I just wanted to ensure that we'd not get any performance regression in gettimeofday() calls.

Here's the output from running this on this windows 8.1 laptop.

D:\>cl /Ox gettimeofday.c
Microsoft (R) C/C++ Optimizing Compiler Version 17.00.61030 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

gettimeofday.c
Microsoft (R) Incremental Linker Version 11.00.61030.0
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:gettimeofday.exe
gettimeofday.obj

D:\>gettimeofday.exe
GetSystemTimePreciseAsFileTime() in 0.157480 seconds
GetSystemTimeAsFileTime() in 0.060075 seconds
Current Method in 0.742677 seconds

Regards

David Rowley

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Wait free LW_SHARED acquisition - v0.2
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: [Windows,PATCH] Use faster, higher precision timer API