John wrote:
> > I was thinking about this.
> > What if you did some samples to decide how long the primitives ran.
> >
> > Say start with an array of flags to indicate if we should
> > check the clock for the primitive in question. If we don't
> > know the state of the flag then collect a few samples of
> > duration, then based on the numbers set the flag as required.

Bad idea. Consider BitBlt - if you draw a string all the prims complete
quickly because the glyphs are very small. And then you have large area
image copy operations which can take quite a bit of time.

Tim replied:
> I think the neat thing about using Slang pragmas to encode
> the checks in the prims themselves is that adding the cost
> of a clock check to a prim that is almost certainly long
> running is a negligable cost. Leaving the check out of a
> known quick prim is likely to be big saving.

And that's the wrong way around because you're making the optimization
(omitting the check) the default.

BTW, in my understanding there should be no need _at_all_ to flag primitives
explicitly or measure the runtime. Part of the idea behind the pluginization
process was that we would have all the indexed primitives be quick and all
the external ones be slow[**] - in other words, once the pluginization were
complete we should be able to simply omit the entire check in primitive
response and add it to #primExternalCall. If there were still some indexed
primitives that needed the check (primitiveBecome comes to mind) then those
should explicitly implement them (or be called by name).

So how's that? Let's just move the clock check over to #primExternalCall and
add a few extra checks for slow-running indexed prims?

[**] The overhead of calling named primitives is (compared to indexed prims)
pretty large and thus the extra amount of the clock check doesn't really
matter.

Cheers,
  - Andreas