It's worth noting that on Darwin (on Apple hardware) gettimeofday is
never a syscall whereas on Linux (AFAIK), it always is.
On Jun 8, 2006, at 7:58 PM, Mark Kirkwood wrote:
> Tom Lane wrote:
>> Alvaro Herrera <alvherre@commandprompt.com> writes:
>>> Wow, that is slow. Maybe a problem in the kernel? Perhaps something
>>> similar to this:
>>> http://www.ussg.iu.edu/hypermail/linux/kernel/0603.2/index.html#1282
>> Yeah, that's a pretty interesting thread. I came across something
>> similar on a Red Hat internal list. It seems there are three or four
>> different popular standards for clock hardware in the Intel world,
>> and some good implementations and some pretty bad implementations
>> of each. So the answer may well boil down to "if you're using cheap
>> junk PC hardware then gettimeofday will be slow".
>
> OS seems to matter as well - I've got two identical Supermicro P3TDER
> dual intel boxes. 1 running FreeBSD 6.1, one running Gentoo Linux
> 2.6.16.
>
> Doing the 'select count(*) vs explain analyze select count(*) on
> 100000 row table gives:
>
> Freebsd : select 108 ms explain analyze 688 ms
> Linux : select 100 ms explain analyze 196 ms
>
> Both systems have ACPI enabled in BIOS (which means there is a better
> timecounter than 'i8254' available (FreeBSD says its using 'ACPI-safe'
> - not sure how to check on Linux).
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
AgentM
agentm@themactionfaction.com
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬