Re: [Squeak-VMdev] primitive timing issues

[Ian P. <ian...@in...>]

Hi Tim,

> I've been messing in the area of primitive calling and found a small
> (5% - pMac) to big (150% - RISC OS) improvement in macrobenchmark
> performance by removing the timing stuff that currently surrounds
> primitive calls. (See primitiveResponse) I moved the timing to
> primitiveExternalCall on the dodgy sounding but surprisingly practical
> grounds that numbered prims are quick

Hmmm.  Like primitives 127, 128 and 130, for example?

;)

How about just changing it all to do The Right Thing.

> To tag the primitives that need this timer check, I suggest that some
> Slang equivalent of a pragma be tossed in. We can automagically add the
> macro reference to each exit.

That sounds like a close approximation to me.  (j5 had a completely 
local set of [numbered] primitive implementations, written by hand from 
scratch, in which I very carefully identified those that could 
potentially run for more than 1ms and avoided the timer check in all 
others.)

> There are however cases where the
> potential slowness is also very platform dependent and we ought to
> handle that. For example, getNextEvent could be very slow on RISC OS if
> it allows some other app to run and that app goes off and calculates pi
> to a gazillion places before returning. Some prims could be made long
> running if they trigger a GC.

In those cases, just fall back on setting interruptCheckCounter to zero 
in your ioGetNextEvent() thing.  (Like you already do, when the user 
presses the interruptKeyCode, right? ;)

> Oh, and some idea of what
> situation originally lead to the prim timing code being added would be
> interesting if anyone remembers.

It had (IIRC) a lot to do with timing a 1ms Delay a zillion times, 
storing the results into a Bag, and then asking for its sortedCounts.

Cheers,
Ian