> From: Tim Rowledge <tim at sumeru.stanford.edu>
> ...

> I've been looking at the code in the sensor related classes after some
> new profiling type tools suggested something is horribly wrong with the
> behaviour of the io system on Acorns.  Little surprises like 
> discovering
> that 65-70% of time is claimed to be spent in EventSensor nextEvent !!
> Like noticing that the check for a chaged Display extent never (well
> occasionaly every few hours) gets to run and so my window resizing code
> looks pointless) and that ioRelinquishProcessor only ever gets to run a
> couple of times when a window is closing.

Well on the mac the ioRelinquishProcessor call happens quite 
consistently, and
cpu time heads towards oh say 10%.

If I remember, it's been years, when we started on the eventensor 
stuff, we had this
issue of creating a structure that looked like it was getting events 
from the vm without polling, but no
vm was multi-threaded so to get events we had to poll, which we were 
not trying to
do in the first place.

Hope you loaded my EventSensorDrivenByVM-JMM, did that do anything?

What you are noticing here is the call to 
EventSensor>>nextEventFromQueue
driven via these two folks, WorldState>>doOneCycleNowFor: & 
PasteUpMorph>>doOneCycleNow.

How fast this is called is regulated with flawed math (see attached 
note) in
WorldState>>interCyclePause:
However if you have Preferences higherPerformance true, then well 
you'll get a call every millisecond or less,
otherwise at target of 20ms (ish) is used.  You don't have 
higherPerformance turned on do you?

Ah, this is also where checkForNewScreenSize happens too.  Also see 
interActivityPause for that too.

Remember last week I said I was seeing millisecond clock calls every 
2-3 milliseconds, that comes from here.
A quick check shows that for me nextEvent -> nextEventFromQueue -> to 
inputSemaphoreSignalNoWait gets invoked
46.6 times per second, which matches the expectations (wrong math) of 
50 times per second.

>
> As part of that I had to look at the code for Sensor/EventSensor. Yuck!
> Surely it can be made simpler and cleaner?

Start coding.

>
> As a start, can anyone explain why eventQueue is non-nil on a machine
> that doesn't use the event input prims yet? This would appear to 
> prevent
> the event synthesizing method from ever running , which makes me wonder
> how my machine ever got anything done. Nilling it out in an inspector
> results in my machine still running but no improvement in the overall
> profile.
>
> tim

Ah, you read the comment in nextEventSynthesized?  & the code in
primGetNextEvent: array
	"Store the next OS event available into the provided array.
	Essential. If the VM is not event driven the ST code will fall
	back to the old-style mechanism and use the state based
	primitives instead."
	| kbd buttons modifiers pos mapped |
	<primitive: 94>

Where if you don't support the event input/queue prim 94, it builds a 
keyboard or mouse event, then
drops it into the queue in ioProcess. which is the event synthesizing.

Also someone might want to digest this old note
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.tiff
Type: image/tiff
Size: 2662 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030709/41cd3a92/image.tiff
-------------- next part --------------


lastCycleTime needs to get initialized somewhere on image restart, and  
one needs to take care about clock rollover and resetting on image  
restart. I fiddled with code like this in testing. If you pull up a  
FrameRateMorphic it should be showing 50 fps. But without this change  
it won't...


interCyclePause: milliSecs
?????"delay enough that the next interaction cycle won't happen too  
soon after the original; thus, if all the system is doing is polling  
for interaction, the overall CPU usage of Squeak will be low"

??????| currentTime wait actualTime |

currentTime _ Time millisecondClockValue.
??????(lastCycleTime notNil and: [CanSurrenderToOS ~~ false]) ifTrue: [
????????????wait _ lastCycleTime + milliSecs - currentTime.
??????????????(wait > 0 and: [(wait <= milliSecs]? "big waits happen  
after a snapshot")
???????????????????????????????????ifTrue: [DisplayScreen  
checkForNewScreenSize.
?????????????????????????????????????
??????????????????????????????????????????(Delay forMilliseconds: wait)  
wait ].
????????].
?????].
?????"record the time AFTER the wait"
???????lastCycleTime _? Time millisecondClockValue.
???CanSurrenderToOS _ true.
???????(wait notNil and: [wait > 0]) ifTrue: [
??????????????actualTime _ (lastCycleTime - currentTime).
??????????????????(actualTime > 0 and: [actualTime < 1000]) ifTrue:
???????????????????????????[actualTime _ actualTime - wait.
????????????????????????????lastCycleTime _ lastCycleTime -  
actualTime]].




To: squeak-dev-lists.squeakfoundati

From: John M McIntosh <johnmci at smalltalkconsulting.com>

Subject: [BUG] why is frame rate in 3.2.5 slower?

Cc:

Bcc:

X-Attachments:



Alain Fischer was kind enough to send me feedback on the 3.2.5 mac  
build process and a wee note about how come the frame rate in 3.2.4 or  
3.2.5 is slower?

(Hint the Morphic folks should start reading very carefully)

3.2.4 I know about, that's a compile time bug fostered on us by a bug  
in Project? Builder.

Now? If you get one bouncing atoms morphic up then a framerate morphic,
then we see

3.2.2? 33-38
3.2.3? 31-38
3.2.4? 24-28? (mmm as expected alas, a compile time bug)
3.2.5? 29-34? (mmmm)


Yet I benched 3.2.1b6 against 3.2.6 macrobenchmarks (which only two  
lucky squeakers have right now) and got very similar numbers (3.2.6 is  
slightly faster) So what gives.

Ah but I noticed that although step time for the bouncing atom morphic  
is 0, There is more that meets the eye.

So I turned higher performance on,
now I get 49-52 frames a second!!!!

mmmm

Ah, so I see there is an attempt to limit cycle rate to 50 per second in
WorldState>>interCyclePause: Mind I'm not sure how that relates to  
frame rate, so why isn't the FrameRateMorph reporting 50 here? (that's  
question one if someone wants to solve it.) Mmm if I let Squeak go  
completely idle we get a frame rate of 31 or so... Odd shouldn't that  
be 50?

Mmm if I put a print to transcript in there and look at the wait time I  
see numbers like
18 15 15 18 18 18 17 17 17 18 17 17 15 18 17 18 15 17 18 18 15 15 17 17  
18
and the frame rate goes to 11...

You know I don't get to play with Morphic much but I see a flaw here.  
Shall I give a clue...

Ok it seems that on the Delay Squeak becomes idle (yes no processes are  
available to run, so the scheduler falls back to run  
primitiveRelinquishProcessor which invokes usleep(microseconds)

Golly if I look at how long it takes between the first time  
MillisecondClockValue and the last why it's

26 20 21 20 25 22 25 24 25 26 23 31 24 23 21 21 24 25 26 25 24 30 25 29  
26 21 28 22 23 26 26 24 23 22 25 30 26 22 30 29 24 25 25 24 40 23

Gee shouldn't that be 18 or so, aren't I delaying for 18 or so ms huh?  
Well yes you are you are delaying for *at least* 18... Oh so if I get  
24 because well I don't get control back, we're asleep etc etc,  
wouldn't that screw up the math?

Short answer - yes.


So if I add the following to WorldState>>interCyclePause: Then when  
Squeak is idle I get 49 to 50 frames a second in the Morphic frame rate  
display. Which is what I though we should get, so I can't have too  
flawed a thought process here.

Hint I've not carefully written this code, but some Morphic whiz?  
should check for flaws. I've not even collapsed some of the assignments.

WorldState>>interCyclePause:
...
CanSurrenderToOS _ true.
???????wait > 0 ifTrue: [

?????????????????????actualTime _ (lastCycleTime - currentTime).
??????????????????actualTime _ actualTime - wait.
??????????????lastCycleTime _ lastCycleTime - actualTime].

and bouncing atoms goes to

39-43



sigh, of course now I need to understand why exactly we have a 5 ms lag  
on returning from Delay. Oh that should be fun to track.



--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===