You could always check Rectangle>>newRectFrom: "Track the outline of a new rectangle until mouse button changes. newFrameBlock produces each new rectangle from the previous" | rect newRect buttonStart buttonNow aHand delay |

delay _ Delay forMilliseconds: 10. buttonStart _ buttonNow _ Sensor anyButtonPressed. rect _ self. Display border: rect width: 2 rule: Form reverse fillColor: Color gray. [buttonNow == buttonStart] whileTrue: [delay wait.

It should start like so? The Delay is important.

#5516 "Change Set: SlowResizeCPU-JMM Date: 21 October 2003 Author: johnmci@smalltalkconsulting.com

In the browser window CPU usage would go to 100% when we enter the resize pane area, or resize the pane. This was due to zero step time for NewHandleMorph a subclass of HandleMorph which looks at cursor location to change the cursor shape. Change step time to 10 ms in HandleMorph to solve this. Then issue is at actual resize time CPU usage goes to 100%. Issue in resize retangle logic (three places) where it watchs the cursor. Change to delay for 10 ms between cursor lookups"

In checking a basic 6665 image without changes it will only hit 50% cpu when dragging a workspace window frame around on my laptop.

On 26-Dec-05, at 11:42 PM, Yar Hwee Boon wrote:

I've just started a fresh Squeak 3.8-6665 running with Mac OS X VM 3.8.9beta7. I've loaded some web development stuff including Seaside, Magma. Morphic response seems horribly slow compared to 3.7. CPU util reads 90-100% when dragging a workspace for eg. and it takes a few seconds to actually see it move. Does anyone know what could be wrong or what diagnostics I can do? I'm on a 1.2 GHz iBook with enough RAM, if it matters at all. Thanks!

-- Hwee Boon http://motionobj.com/blog/ MotionObj (65) 6764-9774

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

Further to my first answer, I think you could also visit WeakArray and inspect the class var FinalizationDependents. Because of changes in when weak objects are collected, ie fixing a bug about when collection was actually done, we now are more likely to perform a finalization pass on each incremental GC pass. If for example you find you have a WeakArray or subclass with say 60,000 entries in the valueDictionary you will find the logic actually scans each entry looking to do the finalization task. Iterating over 60K members every GC event does take some time, ie lots...

You can also check this issue by running a Vm at 3.8.6b3 or earlier against the image and see if you get the same behaviour since that version of the VM does not have the changes to how weak array processing is signaled.

On 26-Dec-05, at 11:42 PM, Yar Hwee Boon wrote:

I've just started a fresh Squeak 3.8-6665 running with Mac OS X VM 3.8.9beta7. I've loaded some web development stuff including Seaside, Magma. Morphic response seems horribly slow compared to 3.7. CPU util reads 90-100% when dragging a workspace for eg. and it takes a few seconds to actually see it move. Does anyone know what could be wrong or what diagnostics I can do? I'm on a 1.2 GHz iBook with enough RAM, if it matters at all. Thanks!

-- Hwee Boon http://motionobj.com/blog/ MotionObj (65) 6764-9774

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