Squeak Performance on WinCE (was: What makes Morphic slow?)

John.Maloney at disney.com John.Maloney at disney.com
Tue Nov 23 17:01:50 UTC 1999


Hi, Dean.

>From:  Dean Swan at MITEL on 11/22/99 01:02 PM
>What seems to be happening is that when the VM calls
>'MsgWaitForMultipleObjects()' in from 'ioMousePoint()' with a wait timeout of 5
>ms, the E-105 will actually wait for up to 50 ms if no events get queued.
>Touching the screen with the pen must queue up enough events to cause it to
>return nearly immediately.

Just as I suspected! I've seen this behavior under quite
a number of OS's. Basically, the OS takes the opportunity
to slow the processor or do something else, since it figures
you're just waiting for an event anyhow.


Re:
>Regarding Andreas's question: "What can we do about it?" - one thing would be to
>only actually poll for mouse events 20 or 30 times per second, based on a timer
>driven process.  Checking any more frequently than that isn't productive,
>because a typical serial mouse sends a 6 byte report @ 1200 bps for changes in
>buttons or mouse location, which gives you at most, 20 reports per second.  Even
>for newer, faster mice that communicate at 9600, that would still be only 160
>events per second.

The Mac implementation does exactly what you suggest. It's
just a few lines to implement, and it really helped the overall
VM performance on fast machines because, as I said, the VM checks
events for a possible interrupt-key press even when it is running
in a tight loop with no I/O. The Mac polls for events at most 30
times/second. (See attached code snippet.)


Re:
>As for the "draining the batteries" issue, I would suggest letting
>'ReliquishProcessorForMilliseconds:' take care of that.  If sending 'mousePoint'
>to 'Sensor' caused the calling process to wait on a Signal that a mouse event is
>ready, then the idle process would be running most of the time, especially if
>the more expensive hardware polls are only done less than 100 times per second.
>Since this would cause the original process to block on a semaphore, the VM
>would allow other processes to run, keeping the system from locking up.  I think
>this sort of thing could make a big difference in performance because 'Sensor
>mousePoint', 'Sensor buttons' and the like are sent *VERY* frequently.

I agree with the first part--that ioReliquishProcessorForMilliseconds()
could be used to suggest letting the processor sleep. This privitive is
called from Squeak's idle process, the process that runs when *nothing*
else can. If you are in Morphic, and nothing is going on, then most
of the time is spent waiting on a Delay. Thus, the idle process will be
running. If you have some animation running that takes more than 50 mSec
per frame, then Morphic won't wait on the Delay and you'll get all
available processor cycles for your animation. This should just work.
We just need to make ioReliquishProcessorForMilliseconds() call
MsgWaitForMultipleObjects().

What you suggest--having Sensor>mousePoint block would keep animations
from running when there were no events. That's no fun! (You probably
planned have an independent thread running the Morphic animation
loop. That would work, of course, but it opens the door to race
conditions that the current single-thead design spares us from.)

Thanks for doing the key experiment. I recommend that we just limit
the event polling frequency and perhaps later make
ioReliquishProcessorForMilliseconds() call MsgWaitForMultipleObjects()
if the battery consumption when running Squeak goes through the
roof.

On a totally different topic: how does the sound recording and
playback work on the E-105? What sampling rates and sample sizes
are supported? Do sound playback and recording work from Squeak?
I've been quite disappointed in the sound recording quality of most
WinCE devices; it is typically very noise, even when you turn off
all compression and use the highest quality settings. I think the
audio signal paths are not well electrically shielded.

	-- John


Here's the Mac code that limits the OS event polling rate to 30/second.

-----------------
int ioProcessEvents(void) {
	/* Process Macintosh events, checking for the interrupt key. Return
	   true if the interrupt key was pressed. */
	int maxPollsPerSec = 30;
	static clock_t nextPollTick = 0;

	if (clock() > nextPollTick) {
		/* time to process events! */
		while (HandleEvents()) {
			/* process all pending events */
		}

		/* wait a while before trying again */
		nextPollTick = clock() + (CLOCKS_PER_SEC / maxPollsPerSec);
	}
	return interruptPending;
}

int ioRelinquishProcessorForMicroseconds(int microSeconds) {
	/* This operation is platform dependent. On the Mac, it simply calls
	 * HandleEvents(), which gives other applications a chance to run.
	 */

	while (HandleEvents()) {
		/* process all pending events */
	}
	return microSeconds;
}
-----------------





More information about the Squeak-dev mailing list