In doing some testing that involved Processes waiting on timers, I was puzzled by poor performance. Digging deeper I finally narrowed it down to this example:

PWatch class>>runTests3:

runTests3: howMany

	| block alone done notAlone |

	alone _ notAlone _ 0.
	block _ [
		Time millisecondsToRun: [100 timesRepeat: [howMany factorial]]
	].
	3 timesRepeat: [alone _ alone + block value].
	done _ false.
	[(Delay forSeconds: 30) wait. done _ true] forkAt: 6.
	3 timesRepeat: [notAlone _ notAlone + block value].
	[done] whileFalse.
	Transcript show: 
		howMany asString,
		' alone = ',(alone // 3) asString,
		'  	notAlone = ',(notAlone // 3) asString; cr.	

Then, when I evaluate:

5 to: 30 by: 5 do: [ :howMany | PWatch runTests3: howMany]

I get:

5 alone = 3  	notAlone = 3
10 alone = 4  	notAlone = 5
15 alone = 54  	notAlone = 292
20 alone = 161  	notAlone = 967
25 alone = 248  	notAlone = 1661
30 alone = 379  	notAlone = 2635

When we go from 10 factorial to 15 factorial (when the result crosses from SmallInteger to LargeInteger), performance drops by a factor of 5 or 6 *IF* another process is waiting on a timer to expire.

Looking at the interpreter source, after every primitive dispatch, there is

	if (successFlag && ((nextWakeupTick != 0) && (((ioMSecs()) & 536870911) >= nextWakeupTick))) {
		interruptCheckCounter = 1000;
		checkForInterrupts();
	}

There are comments (in the Mac version, anyway) as to there being two routines available for getting a millisecond clock value and that the more expensive is used for greater accuracy. Perhaps this might be a spot to use the cheaper variety with a suitable allowance for accuracy.

Any thoughts?

Cheers,
Bob