Scott,

[Re: Using ITIMER]
> I got a few percent speedup as part of this, and I didn't
> have to have any 'this primitive might be slow, this primitive
> is fast' nonsense. I say to reuse this idiom for the other
> platforms?

You are assuming that every platform has a _cheap_ way of querying for some
millisecond value. Effectively, what you did is no different at all from the
current solution: If you have a cheap timer everything's great. If you don't
you're screwed. Even more so because the current primitiveResponse() code
has _three_ calls to timing functions if some delay is activated (two
#ioLowResMSecs and one #ioMSecs call).

My "'this primitive might be slow, this primitive is fast' nonsense" (as you
put it so nicely) is intended to completely REMOVE two out of three calls.
In other words, assume - just for a second - that you have only one way of
querying the timer which is a bit expensive. My solution does require you to
call the timer if and only if something happened that took a long time.

Again, let me repeat (because I think you're not quite realizing what I was
trying to do) my little demo removed two calls to the timer completely. This
is hugely advantageous if you don't happen to have a cheap timer.
Incidentally, I was surprised seeing a 5% improvement on Windows - seems
like the function I'm calling (although according to the docs the fastest by
far) still has some significant overhead.

> I look at Andreas solution as being hard to maintain, in that there
> will be special cases of what named primitives are invoked
> too frequently that reading the clock shouldn't be done, or what
> numbered primitives might run too long that you should read the clock.

I agree. Maintenance is harder with that scheme. But not for named
primitives. Only for the numbered ones. I accept this because numbered prims
are the "basic" primitives which are heavily used and therefore need to be
run at max speed. In those, it is worthwhile to put a bit more effort.

> I believe a few of these exceptions have already been
> enumerated on the list.  I certainly don't want to have to go through
> every primitive to decide if it needs an exception. Or, require future
> primitive writers decide if they need an exception.

You should have had a look at the code first, before writing the above. None
of the above is true except if you write a new numbered primitive which
these days nobody should unless it's time critical - and in these cases you
really _should_ be aware of this implication.

Cheers,
  - Andreas