Hello.

> The variable read may, but the function call overhead doesn't.. Yes,
> it makes it about 10x cheaper. But the correct solution is to *not*
> read the clock 40,000 times a second. Andreas Raab's patch (which
> I referenced) reduces this. If you don't read it 40,000 times a
> second, you're not invoking 40,000 or more functions/second, and its
> going to be better.
> 
> ar's fix is generally applicable, for all platforms. Sure, go for
> ITIMER for UNIX to make the 4000 invocations/second cheaper, but go
> for ar's patch so it reads the clock 36000 times fewer a second.

Just a few thoughts... intel CPUs keep track of how many cycles have
elapsed since they were turned on.  So, a 1GHz cpu increments the
counter (roughly) 10^9 times per second.  Reading this counter takes an
insignificant amount of time to execute.

Of course, nobody should expect to have exactly 1 billion cycles in a
1GHz cpu.  I am assuming most OS know this and adjust properly according
to whatever means they have.  So, wouldn't it be even more efficient if
you read the time off the OS once every appropriate cpu eternity?  Once
you have a proper key time frame, you can update it to reasonable
precision using the cpu cycle counter, and of course only when the
current time is required.

I don't know about mac or other cpus, so maybe this does not apply to
other platforms.

Andres.