Tim,
I tried this in my normal work image (3.2 gamma with all current updates, OS X VM 3.2.6Beta8) and got the attached results. It's been awhile since I tried to interpret a profile like this, but it looks reasonable to me. As far as I can see, a little less than half the time is being spent drawing the menu buttons and so on, and I think some of the rest is going to redraw surrounding parts of the browser and world background because the damage area may be specified larger than it really is (that last is a guess, though). Do you get anything seriously different?
Bruce
At 11:35 PM +0200 8/1/02, Andreas Raab wrote:
Tim,
What performance problems are you seeing?
General tardiness in a non-descript way.
[...]
I suppose we really need some good meaningful test scenarios that can be automated and profiled to really try to sort this out.
Well, then let's get started. You say that opening menus hurts?! So how about (from a workspace):
selectItems := false. "if true, select all the menu items" Browser fullOnClass: Morph selector: #aboutToBeGrabbedBy:. World doOneCycleNow. MessageTally spyOn:[ World firstSubmorph "the app" allMorphsDo:[:m| (m isKindOf: ScrollPane) ifTrue:[ 1 to: 10 do:[:i| (m getMenu: false) ifNotNilDo:[:menu| menu popUpAt: m position forHand: m activeHand in: m world. World doOneCycleNow.
selectItems ifTrue:[ menu submorphs do:[:item| (item isKindOf: MenuItemMorph) ifTrue:[ menu selectItem: item event: m activeHand lastEvent. World doOneCycleNow. ]. ]. ]. menu delete. World doOneCycleNow. ]. ]. ]. ]. ].
That should give you a pretty decent hint about what is going on ;-)
Cheers,
- Andreas