Re: [HACKERS] gettimeofday is at the end of its usefulness?
В списке pgsql-hackers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: [HACKERS] gettimeofday is at the end of its usefulness? |
| Дата | |
| Msg-id | 4130.1483045351@sss.pgh.pa.us обсуждение |
| Ответ на | Re: [HACKERS] gettimeofday is at the end of its usefulness? (Florian Weimer <fw@deneb.enyo.de>) |
| Ответы |
Re: [HACKERS] gettimeofday is at the end of its usefulness?
|
| Список | pgsql-hackers |
Florian Weimer <fw@deneb.enyo.de> writes:
> * 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).
> 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?
No doubt, but I have yet to find a platform where clock_gettime() exists
but performs worse than gettimeofday(). Do you know of one?
regards, tom lane
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера