Lex Spoon wrote:
> Bob Arning  <arning at charm.net> wrote:
[...]
>>This...
>>
>>
>>>  |      |            81.1% {8565ms} DisplayScreen>>forceToScreen:
>>
>>is *much* more than I have ever seen on the Mac and I wonder if unix can be so different. It would be interesting to modify DisplayScreen>>forceToScreen: just a tad to count how many times it is getting called - is this one call that takes a long time or a million calls that take little time each. Also, what is the setting of the preference #higherPerformance?
>>
> 
> 
> Recall that he is running it across the network, and thus
> force-to-screen is much more expensive than unusual.
> 
> BUT -- why is Squeak drawing anything at all?!  What could be on the
> screen that needs updating?
> 
> Julian, is there *any* morph left on the screen?  How about flaps?

Well, the ProcessBrowser is open.  Other than that, no morphs at all.

Ok, strange.  I tried both a 3.5 final and a 3.6b image and they seem to 
spend all their time in Delay>>wait (as expected) and their CPU usage is 
almost naught.  So it appears that this is somehow a problem with the 
specific development image I deployed.  I tried loading Seaside into the 
3.6 image and it made no difference.  I guess I'll just punt on this 
problem for now and report back if I see the problem once I have a newly 
built image.  It feels like we're just flailing at the moment.

I discovered that "Project uiProcess suspend" did wonders for my 
original image's CPU use and I thought that might be the solution.  But 
since the clean images seem to use essentially no CPU anyway, this seems 
to be unnecessary.

Oone last piece of information... I just took my original image and 
opened up the ProcessBrowser.  The UI process is still using ~40%.  Then 
in a workspace, I execute "MessageTally spyOn: [[Sensor peekMousePt y > 
0] whileTrue: [World doOneCycle]]." which is what the World 
Menu/debug/start MessageTally menu item does.  While that MessageTally 
is running, the UI process drops down to 2%, the Delay>>wait process 
goes up to about 20%, and the idle process seems to have the rest.  As 
soon as I move the mouse to the top of the screen the stop the tally, 
the UI process goes back up to ~40%.

Anyway, I'm confused at this point but hopeful that a new image will 
solve the problem.  If anyone really wants to track this down I could 
probably send a copy of the image.  Otherwise... well I'm going to stop 
spending time on it for now :)

Julian