Re: [HACKERS] gettimeofday is at the end of its usefulness?
От | Florian Weimer |
---|---|
Тема | Re: [HACKERS] gettimeofday is at the end of its usefulness? |
Дата | |
Msg-id | 87y3yyfqqe.fsf@mid.deneb.enyo.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] gettimeofday is at the end of its usefulness? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] gettimeofday is at the end of its usefulness?
|
Список | pgsql-hackers |
* Tom Lane: > On Linux (RHEL6, 2.4GHz x86_64), I find that gettimeofday(), > clock_gettime(CLOCK_MONOTONIC), and clock_gettime(CLOCK_REALTIME) > all take about 40ns. Of course gettimeofday() only has 1us resolution, > but the other two have perhaps 10ns resolution (I get no duplicate > readings in a tight loop). Other documented clockids include > CLOCK_REALTIME_COARSE: about 10ns to read, but only 1ms resolution > CLOCK_MONOTONIC_COARSE: about 12ns to read, but only 1ms resolution > CLOCK_MONOTONIC_RAW: full resolution but very slow, ~145ns to read > So CLOCK_MONOTONIC seems to be the thing to use here. It won't buy > us anything speed-wise but the extra resolution will be nice. > However, we need to do more research to see if this holds true on > other popular distros. Isn't this very specific to kernel and glibc versions, depending on things like CONFIG_HZ settings and what level of vDSO support has been backported?
В списке pgsql-hackers по дате отправления: