Tim,

> > 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?
> I think that would make an excellent heuristic.
>
> I suspect there are some indexed prims that might need checks if one
> were to be really pedantic about it. For example, prim117, the
> look-up-the-named-prim primitive pretty much has to be
> indexed (I don't think we could make it look itself up could we?) and
> can take a very long time if a plugin is not loaded. Does it happen
> often enough to matter? Probably not.
> As Andreas says, just about all the currently-index prims that take a
> long time could be recharacterised as named. become:, fullGC, a lot of
> IO & Display prims, etc would be well tackled this way. There
> are a few interesting cases where the normal case is fast but something
> like a GC can be involved; I'd imagine that we could make the GC code
> set an appropriate flag - primMakePoint is an example. Surely there
> are some other awkward cases that would require manual intervention
> but so what.

You have a point here. Just for experimentation I hacked a little CS
(attached) that should handle all cases pretty well - it makes use of a
#timerPending flag which is set if we encounter situations that make the
call to the high-res clock worthwhile (including GCs and some other obscure
situations).

While the tinyBenchmarks are hardly affected at all, I did find a consistent
speedup of ~5% within the macro benchmarks. I'd be interested if others (in
particular on U**x and Mac platforms) find similar results. Please let me
know - if the results are the same then it seems pretty worthwhile.

Cheers,
  - Andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VMTimerPending-ar.2.zip
Type: application/x-zip-compressed
Size: 16344 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20011214/5f75261f/VMTimerPending-ar.2.bin