On windows 98 the new Squeak 3.2 exhibits a quite strange behaviour when a debugger is opened in the MVC environment.
Please try this. 1. create and enter an mvc project. 2. open a class hierarchy browser. 3. select StringHolder>>browseVersions. ( a lot of other methods would do as well. ) 4. Insert the statement self halt. at the beginning of the method and save the method with "accept" 5. Now, move the mouse into the method names view and select "versions" 6. a small red window with title "Halt" and three buttons is opened. Press the button "Resume" 7. a blue (or violet?) VersionsBrowser is opened. It flashes when it is opened and this detail is maybe important. 8. select a version. I see the method text displayed for a very short time, then the text view is empty again.
There are also other weird effects (on my computer at least)
*the system menue shows unusual behavior. *When the mouse pointer leases the versions brwoser and then enters it again, it crosses the window border. When it does, the curser changes to a "drag window border" symbol. That symbol does not vanish again when the mouse pointer is inside the versions browser.
After a lot of nonsensical actions with the mouse Squeak seemingly comes back to normal bahaviour.
I saw these strange things also in a 3.2 alpha (last update: 4599) with the virtual machine Squeak 3.2.2 VM (release candidate) from May 26 2002 Compiler: gcc 2.95.2 19991024 (release)
I think that something with the process switching or scheduling goes wrong, but until now I have no idea what it is.
Are there others out there that can confirm my observations? Have you any idea what I can do to better the situation?
Greetings Boris
The mvc brain-damage Boris describes turns out to be reliably exhibited whenever a debugger is presented and proceeded-through in an MVC project, both in 3.2 *and* 3.3a. Even something as simple as hitting cmd-dot and then hitting the Proceed button on the ensuing pre-debug window (in mvc) will do it.
By going back to an image that did not exhibit these problems and then loading updates one at a time, checking for the bug after each update, I was able to track down exactly where this problem entered into Squeak.
It turns out to have arrived in update 4487SyntaxErrorsOnFileIn-svp, whose preamble was:
-------------------------------------------------- Change Set: SyntaxErrorsOnFileIn-svp Date: 14 October 2001 Author: Stephen Pair
BugFixing Party @ Camp Smalltalk OOPSLA 2001. Fixes bug report from Sept 13, 2001:
If you get a syntax error during a fileIn, you should be able to correct it in the notifier, and then accept the corrected code from that window. If all is well, the method gets defined, and the fileIn continues. But it doesn't. Instead, you get... NonBooleanReceiver: proceed for truth. --------------------------------------------------
That update may have improved things regarding the state after syntax errors are encountered during fileins, but it is seemingly directly responsible for breaking mvc whenever a debugger is put up.
It appears that a simple reversion of the single method in this update (Debugger >> process:controller:context:isolationHead:) cures the problem, though presumably that would re-establish the problem on file-in that the update was intended to fix.
I attach herewith instead a proposed workaround, with the following preamble:
-------------------------------------------------- Change Set: debuggerFix-sw Date: 29 July 2002 Author: Scott Wallace
Works around a bug introduced in update4487SyntaxErrorsOnFileIn-svp (October 2001) which had compromised the mvc environment whenever a debugger was brought up. The workaround here, done without any pretension to deep knowledge of the underlying issues, is to restore the method in question (Debugger >> process:controller:context:isolationHead:) to its former behavior in the mvc case, while letting it work its putative magic when in morphic.
--------------------------------------------------
Before I publish this -- or, preferably, publish someone else's better fix -- as an update, I hope to hear some confirmation or other commentary on this matter, and, ideally, to receive the "real fix" from someone.
Cheers,
-- Scott
At 9:20 AM +0200 7/28/02, Boris Gaertner wrote:
On windows 98 the new Squeak 3.2 exhibits a quite strange behaviour when a debugger is opened in the MVC environment.
Please try this.
- create and enter an mvc project.
- open a class hierarchy browser.
- select StringHolder>>browseVersions. ( a lot of other methods would do as well. )
- Insert the statement self halt. at the beginning of the method and save the method with "accept"
- Now, move the mouse into the method names view and select "versions"
- a small red window with title "Halt" and three buttons
is opened. Press the button "Resume" 7. a blue (or violet?) VersionsBrowser is opened. It flashes when it is opened and this detail is maybe important. 8. select a version. I see the method text displayed for a very short time, then the text view is empty again.
There are also other weird effects (on my computer at least)
*the system menue shows unusual behavior. *When the mouse pointer leases the versions brwoser and then enters it again, it crosses the window border. When it does, the curser changes to a "drag window border" symbol. That symbol does not vanish again when the mouse pointer is inside the versions browser.
After a lot of nonsensical actions with the mouse Squeak seemingly comes back to normal bahaviour.
I saw these strange things also in a 3.2 alpha (last update: 4599) with the virtual machine Squeak 3.2.2 VM (release candidate) from May 26 2002 Compiler: gcc 2.95.2 19991024 (release)
I think that something with the process switching or scheduling goes wrong, but until now I have no idea what it is.
Are there others out there that can confirm my observations? Have you any idea what I can do to better the situation?
Greetings Boris
It seems to me that no Squeaker could plausibly have been doing any real work in MVC in any 3.2 or 3.3a since this bug arrived more than eight months ago, because the mere raising of a single debugger would have put his environment into a state no reasonable person could tolerate. And he would therefore have screamed and we would have heard.
Consequently, I'm not too surprised that there has not been a single response posted to this thread, other than Boris's original bug report and my reply.
But is it really true that there are actually *no* MVC practitioners using either Squeak 3.2 or 3.3a , no one at all, except Boris?
Cheers,
-- Scott
At 2:46 AM -0700 7/30/02, Scott Wallace wrote:
The mvc brain-damage Boris describes turns out to be reliably exhibited whenever a debugger is presented and proceeded-through in an MVC project, both in 3.2 *and* 3.3a. Even something as simple as hitting cmd-dot and then hitting the Proceed button on the ensuing pre-debug window (in mvc) will do it.
By going back to an image that did not exhibit these problems and then loading updates one at a time, checking for the bug after each update, I was able to track down exactly where this problem entered into Squeak.
It turns out to have arrived in update 4487SyntaxErrorsOnFileIn-svp, whose preamble was:
Change Set: SyntaxErrorsOnFileIn-svp Date: 14 October 2001 Author: Stephen Pair
BugFixing Party @ Camp Smalltalk OOPSLA 2001. Fixes bug report from Sept 13, 2001:
If you get a syntax error during a fileIn, you should be able to correct it in the notifier, and then accept the corrected code from that window. If all is well, the method gets defined, and the fileIn continues. But it doesn't. Instead, you get... NonBooleanReceiver: proceed for truth.
That update may have improved things regarding the state after syntax errors are encountered during fileins, but it is seemingly directly responsible for breaking mvc whenever a debugger is put up.
It appears that a simple reversion of the single method in this update (Debugger >> process:controller:context:isolationHead:) cures the problem, though presumably that would re-establish the problem on file-in that the update was intended to fix.
I attach herewith instead a proposed workaround, with the following preamble:
Change Set: debuggerFix-sw Date: 29 July 2002 Author: Scott Wallace
Works around a bug introduced in update4487SyntaxErrorsOnFileIn-svp (October 2001) which had compromised the mvc environment whenever a debugger was brought up. The workaround here, done without any pretension to deep knowledge of the underlying issues, is to restore the method in question (Debugger >> process:controller:context:isolationHead:) to its former behavior in the mvc case, while letting it work its putative magic when in morphic.
Before I publish this -- or, preferably, publish someone else's better fix -- as an update, I hope to hear some confirmation or other commentary on this matter, and, ideally, to receive the "real fix" from someone.
Cheers,
-- Scott
At 9:20 AM +0200 7/28/02, Boris Gaertner wrote:
On windows 98 the new Squeak 3.2 exhibits a quite strange behaviour when a debugger is opened in the MVC environment.
Please try this.
- create and enter an mvc project.
- open a class hierarchy browser.
- select StringHolder>>browseVersions. ( a lot of other methods would do as well. )
- Insert the statement self halt. at the beginning of the method and save the method with "accept"
- Now, move the mouse into the method names view and select "versions"
- a small red window with title "Halt" and three buttons
is opened. Press the button "Resume" 7. a blue (or violet?) VersionsBrowser is opened. It flashes when it is opened and this detail is maybe important. 8. select a version. I see the method text displayed for a very short time, then the text view is empty again.
There are also other weird effects (on my computer at least)
*the system menue shows unusual behavior. *When the mouse pointer leases the versions brwoser and then enters it again, it crosses the window border. When it does, the curser changes to a "drag window border" symbol. That symbol does not vanish again when the mouse pointer is inside the versions browser.
After a lot of nonsensical actions with the mouse Squeak seemingly comes back to normal bahaviour.
I saw these strange things also in a 3.2 alpha (last update: 4599) with the virtual machine Squeak 3.2.2 VM (release candidate) from May 26 2002 Compiler: gcc 2.95.2 19991024 (release)
I think that something with the process switching or scheduling goes wrong, but until now I have no idea what it is.
Are there others out there that can confirm my observations? Have you any idea what I can do to better the situation?
Greetings Boris
Whilst perusing the 2002 OOPSLA Advance Program that arrived in my mail today, I noticed:
http://oopsla.acm.org/ap/files/tut-21.html
Note the reference to Squeak in the last paragraph. Looks like there is also a workshop on the topic:
http://oopsla.acm.org/ap/files/wor-24.html
david
-- David Farber dfarber@numenor.com
Hi all!
Quoting David Farber dfarber@numenor.com:
Whilst perusing the 2002 OOPSLA Advance Program that arrived in my mail today, I noticed:
http://oopsla.acm.org/ap/files/tut-21.html
Note the reference to Squeak in the last paragraph. Looks like there is
[SNIP]
And I noticed 2 things:
1. That Henrik Gedenryd (with others) is holding some debate panel called "New Programming Constructs Beyond Inheritance, Patterns, and Notation: What's left?". Quote: "The panel looks at what we can hope for in new programming constructs or new programming languages". Cool! Go Henrik. Will it perhaps include some aspect weaving etc? :-)
2. Bill Gates (!) is an invited speaker! My god, what is the world coming to? I just can not miss that speech. Three questions that pop up in my mind: 1. Will he have anything concrete and interesting to say or will it just be "fluff"? 2. In how many ways will he get fried by the audience and is he prepared for that? :-) 3. Is Microsoft finally going to have a presence at OOPSLA? Last year there was a booth in the exhibition hall I can recall, but it was almost always empty...
regards, Göran
Göran Hultgren, goran.hultgren@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek
Scott Wallace scott.wallace@squeakland.org asked...
It seems to me that no Squeaker could plausibly have been doing any real work in MVC in any 3.2 or 3.3a since this bug arrived more than eight months ago, because the mere raising of a single debugger would have put his environment into a state no reasonable person could tolerate. And he would therefore have screamed and we would have heard.
Consequently, I'm not too surprised that there has not been a single response posted to this thread, other than Boris's original bug report and my reply.
But is it really true that there are actually *no* MVC practitioners using either Squeak 3.2 or 3.3a , no one at all, except Boris?
I believe it may be the case that MVC users also tend to use stable releases, and therefore many may still be using 2.8.
So if you are or might be an MVC user, in addition to answering Scott, please say...
What release do you use now?
Do you plan to move to 3.2 in the near future?
Thanks - Dan
Dan Ingalls Dan@SqueakLand.org is claimed by the authorities to have written:
Scott Wallace scott.wallace@squeakland.org asked...
It seems to me that no Squeaker could plausibly have been doing any real work in MVC in any 3.2 or 3.3a since this bug arrived more than eight months ago, because the mere raising of a single debugger would have put his environment into a state no reasonable person could tolerate. And he would therefore have screamed and we would have heard.
I use MVC virtually all the time on my Acorn because Morphic is so damn unusably slow. I hadn't noticed anything untoward (maybe I just don't cause notifiers much after all these years) except maybe one occasion when it seemed like a similar chaos was unleashed. I don't remember what I did about it but it can't have been too traumatic at the time or I would have indeed screamed.
I have noticed a) that MVC has been getting slower somehow - missing events in some fashion perhaps. This is despite having sped up the Acorn vm by 20% recently.
b) that morphic is close to unusable on my pBook 400 OS-X machine and on my linux machine (p3/800 or something) these days.
I'm using 3.2 release and have been on 3.2 track since it started. I don't use 3.3 at the moment.
tim
At 3:16 PM -0700 7/31/02, Tim Rowledge wrote:
I have noticed a) that MVC has been getting slower somehow - missing events in some fashion perhaps. This is despite having sped up the Acorn vm by 20% recently.
b) that morphic is close to unusable on my pBook 400 OS-X machine and on my linux machine (p3/800 or something) these days.
Hmm ... I'm using 3.2 gamma with all updates on a 400 meg PowerBook OS X right now and doing almost nothing *but* Morphic programming. Its' not super-speedy, but performance is OK except when I try to run too many things at once (like putting "self halt" in a method that gets called every 20 milliseconds from a separate thread; very droll :-(. The one place where I would like more performance is when trying to playback a previously recorded event stream; sometimes the playback just can't keep up if there's something else going on. But that's also somewhat of an edge case. What performance problems are you seeing?
I'm using 3.2 release and have been on 3.2 track since it started. I don't use 3.3 at the moment.
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- A 10K brain attached to a 9600 baud mouth.
In message <a05100307b96e66509feb@[10.0.0.2]> Bruce Cohen brucecohen@qwest.net wrote:
At 3:16 PM -0700 7/31/02, Tim Rowledge wrote:
b) that morphic is close to unusable on my pBook 400 OS-X machine and on my linux machine (p3/800 or something) these days.
Hmm ... I'm using 3.2 gamma with all updates on a 400 meg PowerBook OS X right now and doing almost nothing *but* Morphic programming. Its' not super-speedy, but performance is OK except when I try to run too many things at once (like putting "self halt" in a method that gets called every 20 milliseconds from a separate thread; very droll :-(. The one place where I would like more performance is when trying to playback a previously recorded event stream; sometimes the playback just can't keep up if there's something else going on. But that's also somewhat of an edge case. What performance problems are you seeing?
General tardiness in a non-descript way. I suspect that it's not so much Morphic qua Morphic, but inadequately optimised applications of it. For example, opening a menu in many browser places is taking maybe a quarter second, which might sound good but is actually almost perfectly irritating. Anything over 0.1 sec for something like that is just plain bad. On my Acorn machine for example, native menus typically appear about synchronously with the mouse button click reaching ones ear. Really! Remember, this is a _slow_ machine as well.
I suppose we really need some good meaningful test scenarios that can be automated and profiled to really try to sort this out. Then we could find out where the time is really going and do something about it. It wouldn't shock me to find out that somethings are being done two or more times instead of once, for example. Some sensible caching might prove useful.
tim
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
Hi guys!
Quoting Andreas Raab Andreas.Raab@gmx.de:
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
[SNIP of tricky code]
I also got triggered by Tim but since I know "nada" about how Morphic works "inside" I just fling in a "0 halt", investigated the stack to find out where the heck the Events "get born" and thought I could just insert some tallying around the Event processing...
Of course this isn't so easy - you need several iterations to get any interesting results and I couldn't just insert a loop because that would sortof "mess things up badly" so finally to my question:
1. Could we extend the MessageTally class so that we could create an instance once and then let it spy on a certain piece of code over and over again and thus accumulating "real data" but only about the piece of code we are interested in?
Wouldn't this be useful? We could also use it with Wrappers to even more "pinpoint" the code we want to study.
Or am I talking jibberish?
regards, Göran
Göran Hultgren, goran.hultgren@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek
Göran,
I think it mostly depends on what you are trying to do. In Morphic, measuring the "time to handle an event" is an utterly meaningless measure for responsiveness because you are neglecting important other parts of the system (such as time spent in layout, redrawing, stepping etc). This is why there were all of those "doOneCycleNow" spread out in the places (removing them will make the code almost infinitely faster). Also, what the code I sent around was intended for is to get a general feeling for "what part to look first" in order to find good candidates for looking closer. What it should tell us is not which method exactly to look at but to compare how much time is spent in construction, interaction, repainting and other parts that relate to UI feel.
Cheers, - Andreas
-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org] On Behalf Of Göran Hultgren Sent: Friday, August 02, 2002 12:14 AM To: squeak-dev@lists.squeakfoundation.org Subject: RE: Morphic slowness (was Re: Does *anyone* use MVC?)
Hi guys!
Quoting Andreas Raab Andreas.Raab@gmx.de:
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 [SNIP of tricky code]
I also got triggered by Tim but since I know "nada" about how Morphic works "inside" I just fling in a "0 halt", investigated the stack to find out where the heck the Events "get born" and thought I could just insert some tallying around the Event processing...
Of course this isn't so easy - you need several iterations to get any interesting results and I couldn't just insert a loop because that would sortof "mess things up badly" so finally to my question:
- Could we extend the MessageTally class so that we could
create an instance once and then let it spy on a certain piece of code over and over again and thus accumulating "real data" but only about the piece of code we are interested in?
Wouldn't this be useful? We could also use it with Wrappers to even more "pinpoint" the code we want to study.
Or am I talking jibberish?
regards, Göran
Göran Hultgren, goran.hultgren@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek
Hi all!
Quoting Andreas Raab Andreas.Raab@gmx.de:
Göran,
I think it mostly depends on what you are trying to do. In Morphic,
Ah, you are so diplomatic! :-)
measuring the "time to handle an event" is an utterly meaningless measure for responsiveness because you are neglecting important other parts of the system (such as time spent in layout, redrawing, stepping etc). This is why there were all of those "doOneCycleNow" spread out in
Ok, but if we had the functionality I talked about we could perhaps tally those parts "separately" from each other. For example, I assume that somewhere there are a few message sends that could be considered the "redrawing entry points". If we then could instantiate a tallyer and let him cover just that code, then we can have other tallyers for the other parts... Or?
Cheers, Göran
Göran Hultgren, goran.hultgren@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek
Göran,
Ah, you are so diplomatic! :-)
Not really - all I am trying to say is that you shouldn't judge Morphic's responsiveness based on only a tiny subset of all the information you need to take into account. I don't mean to say that having the ability in message tally would be useless/undesirable - just that the results have to be interpreted correctly and if it's UI responsiveness we're after you need to look at the global picture.
Cheers, - Andreas
On Thursday 01 August 2002 03:14 pm, Göran Hultgren wrote:
- Could we extend the MessageTally class so that we could create
an instance once and then let it spy on a certain piece of code over and over again and thus accumulating "real data" but only about the piece of code we are interested in?
You can spy on a Process.
So you can easily build a little script that exercises the UI, and then profile the UI until it's done.
This is something you'd do from a Workspace:
p _ Processor activeProcess. done _ false. e _ ActiveEvent. [ MessageTally spyOnProcess: p forMilliseconds: 10000 toFileNamed: 'uiSpy.out'. done _ true. ] fork. [ done ] whileFalse: [ m _ World putUpWorldMenu: e. World doOneCycleNow. m delete. World doOneCycleNow. ].
Hi all!
Quoting Ned Konz ned@bike-nomad.com:
On Thursday 01 August 2002 03:14 pm, Göran Hultgren wrote:
- Could we extend the MessageTally class so that we could create
an instance once and then let it spy on a certain piece of code over and over again and thus accumulating "real data" but only about the piece of code we are interested in?
You can spy on a Process.
So you can easily build a little script that exercises the UI, and then profile the UI until it's done.
Yes, ok, I saw that - but that is not really what I want. I would like to do this:
Smalltalk at: #MyTallyer put: MessageTally new. 10 timesRepeat: [ <some code I don't want to tally> MyTallyer spy: [ <some code> ]. <some code I don't want to tally> MyTallyer spy: [ <some other code> ]. ]. MyTallyer openUpInSomeFancyToolWhatever...
:-)
Then we could select the pieces we want and the pieces we don't want even! We could of course use "MyTallyer pause" and "MyTallyer resume" too.
regards, Göran
Göran Hultgren, goran.hultgren@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek
On Thursday 01 August 2002 04:17 pm, Göran Hultgren wrote:
Then we could select the pieces we want and the pieces we don't want even! We could of course use "MyTallyer pause" and "MyTallyer resume" too.
Well, I don't know about them, but I just posted a CS that allows cumulative tallying.
On Thursday 01 August 2002 02:35 pm, Andreas Raab wrote:
Well, then let's get started. You say that opening menus hurts?! So how about (from a workspace):
Here's what I tried on my WinCE machine (131MHz MIPS).
It takes 4.2 seconds to open the World Menu (and about 1 second to see characters that I type into a Workspace!).
If I move the menu around, it jerks from place to place at about 4 updates per second.
(It takes 70msec to open the World menu on my 1200MHz Duron).
It takes (with the same VM) 2.3 seconds to open the World menu in the Dynapad image (which is a 2.8/2359 image). Character delays when typing into a Workspace are almost unnoticeable under 2.8.
Dragging the World menu around, I see updates happening maybe 10 times per second.
In 3.2, I did this:
MessageTally spyOn: [ World putUpWorldMenu: ActiveEvent ]
From this, I see a few things that are really slow:
1.9 seconds is spent doing layout with a TableLayout (which is probably overkill for a MenuMorph anyway). (I suspect that the layout is happening each time that a menu item is being added).
0.5 seconds is spent setting up BalloonTexts, most of this in truncating Strings (!)
0.5 seconds is spent on getting the pushpin image for the titlebar. I need to cache that...
And, though I don't see where it's happening,
1.3 seconds is spent looking through IdentityDictionaries. Presumably this is looking for Morph properties and preferences.
So what would you attack first?
I'd first see if I couldn't dispense with the TableLayout in the MenuMorphs.
I'd also cache the pushpin image, and maybe add a preference for simpler menu titlebars.
I'd look into where all the property scanning is going on, and see if I couldn't reduce it.
Maybe we need to add another instance variable or two to the MorphExtensions.
- 154 tallies, 4262 msec.
**Tree** 96.8% {4126ms} PasteUpMorph>>putUpWorldMenu: |53.9% {2297ms} MenuMorph>>popUpEvent:in: | |53.9% {2297ms} MenuMorph>>popUpAt:forHand:in: | | 53.9% {2297ms} MenuMorph>>popUpAt:forHand:in:allowKeyboard: | | 46.8% {1995ms} PasteUpMorph>>addMorphFront: | | |46.8% {1995ms} PasteUpMorph(Morph)>>addMorphInFrontOfLayer: | | | 46.8% {1995ms} PasteUpMorph(Morph)>>addMorph:inFrontOf: | | | 46.8% {1995ms} PasteUpMorph(Morph)>>privateAddMorph:atIndex: | | | 44.8% {1909ms} PasteUpMorph(Morph)>>addedOrRemovedSubmorph: | | | 44.8% {1909ms} MenuMorph(Morph)>>fullBounds | | | 44.8% {1909ms} MenuMorph(Morph)>>doLayoutIn: | | | 41.6% {1773ms} TableLayout>>layout:in: | | | |41.6% {1773ms} TableLayout>>layoutTopToBottom:in: | | | | 31.8% {1355ms} AlignmentMorph(Morph)>>layoutInBounds: | | | | |21.4% {912ms} MenuItemMorph(Morph)>>bounds: | | | | | |13.0% {554ms} MenuItemMorph(Morph)>>position: | | | | | | |9.1% {388ms} MenuItemMorph(Morph)>>invalidRect: [9.1% {388ms} MenuItemMorph(Morph)>>invalidRect:from: [ 7.8% {332ms} MenuMorph(Morph)>>invalidRect:from: [ 7.1% {303ms} PasteUpMorph>>invalidRect:from: [ 6.5% {277ms} WorldState>>recordDamagedRect: [ 6.5% {277ms} DamageRecorder>>recordInvalidRect: [ 5.8% {247ms} Rectangle>>intersect: [ 5.8% {247ms} Rectangle class>>origin:corner: | | | | | | |3.9% {166ms} MenuItemMorph(Morph)>>privateFullMoveBy: [2.6% {111ms} MenuItemMorph(Morph)>>privateMoveBy: | | | | | |8.4% {358ms} MenuItemMorph(Morph)>>extent: | | | | | | 8.4% {358ms} MenuItemMorph(Morph)>>changed [7.1% {303ms} MenuItemMorph(Morph)>>invalidRect: [ 7.1% {303ms} MenuItemMorph(Morph)>>invalidRect:from: [ 7.1% {303ms} MenuMorph(Morph)>>invalidRect:from: [ 4.5% {192ms} PasteUpMorph>>invalidRect:from: [ 4.5% {192ms} WorldState>>recordDamagedRect: [ 4.5% {192ms} DamageRecorder>>recordInvalidRect: [ 3.9% {166ms} Rectangle>>intersect: [ 3.9% {166ms} Rectangle class>>origin:corner: | | | | |5.2% {222ms} AlignmentMorph(Morph)>>doLayoutIn: | | | | | 2.6% {111ms} TableLayout>>layout:in: | | | | | 2.6% {111ms} TableLayout>>layoutLeftToRight:in: [2.6% {111ms} AlignmentMorph(Morph)>>layoutInBounds: | | | | 7.8% {332ms} AlignmentMorph(Morph)>>minExtent | | | | 3.9% {166ms} MenuItemMorph(StringMorph)>>fullBounds | | | | 3.9% {166ms} MenuItemMorph(Morph)>>fullBounds | | | | 3.9% {166ms} MenuItemMorph(Morph)>>doLayoutIn: [3.9% {166ms} MenuItemMorph(Morph)>>outerBounds | | | 3.2% {136ms} MenuMorph(Morph)>>adjustLayoutBounds | | | 2.6% {111ms} MenuMorph(Morph)>>submorphBounds | | | 2.6% {111ms} MenuItemMorph(StringMorph)>>fullBounds | | | 2.6% {111ms} MenuItemMorph(Morph)>>fullBounds | | 4.5% {192ms} MenuMorph>>positionAt:relativeTo:inWorld: | | 4.5% {192ms} MenuMorph(Morph)>>position: | | 3.2% {136ms} MenuMorph(Morph)>>privateFullMoveBy: | | 3.2% {136ms} MenuLineMorph(Morph)>>privateFullMoveBy: | | 3.2% {136ms} MenuLineMorph(Morph)>>privateMoveBy: |22.7% {967ms} PasteUpMorph>>buildWorldMenu: | |22.7% {967ms} TheWorldMenu>>buildWorldMenu | | 21.4% {912ms} TheWorldMenu>>fillIn:from: | | 11.7% {499ms} MenuMorph>>balloonTextForLastItem: | | |11.7% {499ms} MenuItemMorph(Morph)>>setBalloonText: | | | 10.4% {443ms} MenuItemMorph(Morph)>>setBalloonText:maxLineLength: | | | 10.4% {443ms} String>>withNoLineLongerThan: | | | 3.2% {136ms} String(SequenceableCollection)>>, | | | |2.6% {111ms} String(SequenceableCollection)>>copyReplaceFrom:to:with: | | | 2.6% {111ms} String>>withBlanksTrimmed | | 8.4% {358ms} MenuMorph>>add:target:selector:argumentList: | | 5.2% {222ms} MenuItemMorph class(Morph class)>>new | | 5.2% {222ms} MenuItemMorph>>initialize | | 4.5% {192ms} MenuItemMorph(Morph)>>hResizing: | | 4.5% {192ms} MenuItemMorph(Morph)>>assureLayoutProperties | | 4.5% {192ms} MenuItemMorph(Morph)>>layoutProperties: | | 3.9% {166ms} MorphExtension>>layoutProperties: | | 3.9% {166ms} MorphExtension>>setProperty:toValue: | | 3.2% {136ms} IdentityDictionary(Dictionary)>>at:put: |18.8% {801ms} MenuMorph>>addTitle: | 18.8% {801ms} MenuMorph>>addTitle:updatingSelector:updateTarget: | 17.5% {746ms} MenuMorph>>addStayUpIcons | 11.7% {499ms} MenuMorph class>>pushPinImage | 11.7% {499ms} ColorForm>>colorsFromArray: | 11.7% {499ms} Color class>>fromArray: | 9.1% {388ms} Color class>>r:g:b: | |6.5% {277ms} Color>>setRed:green:blue: | | |6.5% {277ms} Float>>rounded | |2.6% {111ms} primitives | 2.6% {111ms} primitives 3.2% {136ms} MessageTally class>>spyOn:toFileNamed: 3.2% {136ms} MessageTally>>spyEvery:on: 3.2% {136ms} SmallInteger>>- 3.2% {136ms} SmallInteger(Integer)>>- 3.2% {136ms} Array(Object)>>adaptToInteger:andSend: 3.2% {136ms} Array(Collection)>>adaptToNumber:andSend:
**Leaves** 31.8% {1355ms} IdentityDictionary>>scanFor: 16.9% {720ms} Rectangle class>>origin:corner: 6.5% {277ms} Float>>rounded 4.5% {192ms} Point>>+ 3.9% {166ms} Array(SequenceableCollection)>>copyReplaceFrom:to:with: 3.2% {136ms} Color class>>r:g:b: 3.2% {136ms} String(SequenceableCollection)>>copyFrom:to: 3.2% {136ms} Array(Collection)>>adaptToNumber:andSend: 2.6% {111ms} Color class>>fromArray: 2.6% {111ms} MethodDictionary>>includesKey:
**Memory** old +57,416 bytes young -151,120 bytes used -93,704 bytes free +93,704 bytes
**GCs** full 0 totalling 0ms (0.0% uptime) incr 9 totalling 187ms (4.0% uptime), avg 21.0ms tenures 1 (avg 9 GCs/tenure) root table 0 overflows
Ned Konz ned@bike-nomad.com is claimed by the authorities to have written:
On Thursday 01 August 2002 02:35 pm, Andreas Raab wrote:
Well, then let's get started. You say that opening menus hurts?! So how about (from a workspace):
Here's what I tried on my WinCE machine (131MHz MIPS).
It takes 4.2 seconds to open the World Menu (and about 1 second to see characters that I type into a Workspace!).
Yow!
If I move the menu around, it jerks from place to place at about 4 updates per second.
(It takes 70msec to open the World menu on my 1200MHz Duron).
Now _that_ is scary; on a big fast machine it is only just acceptably fast.
tim
Ned,
Here's what I tried on my WinCE machine (131MHz MIPS).
It takes 4.2 seconds to open the World Menu (and about 1 second to see characters that I type into a Workspace!).
Boy, this sucks...
1.9 seconds is spent doing layout with a TableLayout (which is probably overkill for a MenuMorph anyway). (I suspect that the layout is happening each time that a menu item is being added).
Ah, yes. My "favourite" morphic inefficiency. The problem is that Morphs dump their fullBounds (e.g., the rectangle describing the composite bounds of the morph and its submorphs) to indicate that they need a new layout but naturally, for correct invalidation the full bounds are just what we absolutely need! So whenever we invalidate a morph which needs a new layout we will end up with:
44.8% {1909ms} PasteUpMorph(Morph)>>addedOrRemovedSubmorph: 44.8% {1909ms} MenuMorph(Morph)>>fullBounds 44.8% {1909ms} MenuMorph(Morph)>>doLayoutIn:
0.5 seconds is spent setting up BalloonTexts, most of this in truncating Strings (!)
Which could probably be handled by just using the #balloonTextSelector to construct the balloon help dynamically (hey, that's what it's good for ;-)
0.5 seconds is spent on getting the pushpin image for the titlebar. I need to cache that...
Probably so ;-)
And, though I don't see where it's happening,
1.3 seconds is spent looking through IdentityDictionaries. Presumably this is looking for Morph properties and preferences.
Very likely, although I wouldn't bother too much about it at this point. If you can fix some of the other problems the tallies will show much clearer where the time is spent.
So what would you attack first?
Balloon help and pin-form. Both of them have obvious solutions.
I'd first see if I couldn't dispense with the TableLayout in the MenuMorphs.
You could try that but it's a workaround at best. See above. This problem comes in a variety of places and is by no means limited to menus (although it shows there in quite unacceptable ways).
I'd look into where all the property scanning is going on, and see if I couldn't reduce it.
Wouldn't even bother with it at this point. If you can't say where it's coming from you can't really do anything about the critical places.
Cheers, - Andreas
On Thursday 01 August 2002 04:29 pm, Andreas Raab wrote:
0.5 seconds is spent setting up BalloonTexts, most of this in truncating Strings (!)
Which could probably be handled by just using the #balloonTextSelector to construct the balloon help dynamically (hey, that's what it's good for ;-)
0.5 seconds is spent on getting the pushpin image for the titlebar. I need to cache that...
Probably so ;-)
OK, so I improved those.
Now I'm down from 4.3 seconds to 3.8 seconds.
Now, does anyone have a clue as to why a 2.8 image on the same VM and machine is only taking 2.3 seconds to open (almost) the same menu?
Have we improved Squeak *that* much?
On Fri, 2 Aug 2002 01:29:35 +0200, "Andreas Raab" Andreas.Raab@gmx.de writes:
Ned,
I'd look into where all the property scanning is going on, and see if I couldn't reduce it.
Wouldn't even bother with it at this point. If you can't say where it's coming from you can't really do anything about the critical places.
You forgot to look at the leaves:
**Leaves** 31.8% {1355ms} IdentityDictionary>>scanFor:
Thats 30% right there, thats probably included as parts in the 'other' function profiles.
See my other message.
Scott
On Thu, 1 Aug 2002 15:44:37 -0700, Ned Konz ned@bike-nomad.com writes:
1.3 seconds is spent looking through IdentityDictionaries. Presumably this is looking for Morph properties and preferences.
If any of these dictionaries are, say, >2000 in size, this could be from the identitydictionary thing I was talking about about 9 months ago. Given that (as below) 30% of the total time is spent there, I'd bet you this is rearing its ugly head... *again*
So what would you attack first?
I also posted a changeset that increased the granularity of MessageTally. (Have it tally things more often and to display things even if they have a couple of tally's.) I did this because functions listed in the 'slowest functions' list never appeared in the tree, so you couldn't figure out WHO was calling them.
Called 'CrosbyPrefs.4.cs' I believe.
I'd first see if I couldn't dispense with the TableLayout in the MenuMorphs.
I'd also cache the pushpin image, and maybe add a preference for simpler menu titlebars.
I'd look into where all the property scanning is going on, and see if I couldn't reduce it.
See above.
**Leaves** 31.8% {1355ms} IdentityDictionary>>scanFor:
Also keep in mind that my image patches posted about 4 months ago make my image about twice as fast as stock (on macroBenchmarks)[1]... and if this sort of thing is endemic within morphic, it may even be faster than I realized.[2]
Scott
[1] New method cache. No need for fullGC on root table overflow. And not having primitiveResponse read the clock 80,000 times/second. (I used ITIMER, but AR had a better general solution.) [2] Also threw in the identity**** fixups.. Those are worth about 3 orders of magnitude on some workloads.
"Andreas Raab" Andreas.Raab@gmx.de is claimed by the authorities to have written:
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):
Hokay, on my Acorn this resuts in:- - 2829 tallies, 66170 msec.
**Tree** 75.3% {49826ms} PasteUpMorph>>doOneCycleNow |75.3% {49826ms} WorldState>>doOneCycleNowFor: | 71.7% {47444ms} WorldState>>displayWorldSafely: | |71.5% {47312ms} PasteUpMorph>>displayWorld | | 71.4% {47245ms} PasteUpMorph>>privateOuterDisplayWorld | | 71.4% {47245ms} WorldState>>displayWorld:submorphs: | | 61.7% {40827ms} WorldState>>drawWorld:submorphs:invalidAreasOn: | | |59.2% {39173ms} FormCanvas(Canvas)>>fullDrawMorph: | | | 59.2% {39173ms} FormCanvas(Canvas)>>fullDraw: | | | 59.2% {39173ms} SystemWindow(Morph)>>fullDrawOn: | | | 54.7% {36195ms} SystemWindow(Morph)>>drawSubmorphsOn: | | | |54.4% {35996ms} FormCanvas(Canvas)>>fullDrawMorph: | | | | 54.3% {35930ms} FormCanvas(Canvas)>>fullDraw: | | | | 54.3% {35930ms} AlignmentMorph(Morph)>>fullDrawOn: | | | | 40.1% {26534ms} AlignmentMorph(Morph)>>drawSubmorphsOn: | | | | |39.8% {26336ms} FormCanvas(Canvas)>>fullDrawMorph: | | | | | 39.7% {26269ms} FormCanvas(Canvas)>>fullDraw: [39.5% {26137ms} RectangleMorph(Morph)>>fullDrawOn: [ 11.0% {7279ms} FormCanvas(Canvas)>>roundCornersOf:during: [ |11.0% {7279ms} FormCanvas>>roundCornersOf:in:during: [ | 10.5% {6948ms} CornerRounder class>>roundCornersOf:on:i...orderWidth:corners: [ | 7.4% {4897ms} CornerRounder>>tweakCornersOf:on:in:borderWidth:corners: [ | |2.2% {1456ms} Form(DisplayObject)>>displayOn:at:rule: [ | 3.1% {2051ms} CornerRounder>>saveBitsUnderCornersOf:on:in:corners: [ 10.8% {7146ms} IconicButton(Morph)>>drawSubmorphsOn: [ |10.5% {6948ms} FormCanvas(Canvas)>>fullDrawMorph: [ | 10.4% {6882ms} FormCanvas(Canvas)>>fullDraw: [ | 10.3% {6816ms} SketchMorph(Morph)>>fullDrawOn: [ | 3.1% {2051ms} TransformMorph>>drawSubmorphsOn: [ | |3.0% {1985ms} FormCanvas(Canvas)>>fullDrawMorph: [ | | 3.0% {1985ms} FormCanvas(Canvas)>>fullDraw: [ | | 3.0% {1985ms} TextMorphForEditView(Morph)>>fullDrawOn: [ | | 2.7% {1787ms} FormCanvas(Canvas)>>drawMorph: [ | | 2.7% {1787ms} FormCanvas(Canvas)>>draw: [ | 3.0% {1985ms} FormCanvas(Canvas)>>roundCornersOf:during: [ | |3.0% {1985ms} FormCanvas>>roundCornersOf:in:during: [ | | 2.9% {1919ms} CornerRounder class>>roundCornersOf:on:i...orderWidth:corners: [ | 2.2% {1456ms} FormCanvas(Canvas)>>drawMorph: [ | 2.2% {1456ms} FormCanvas(Canvas)>>draw: [ 8.8% {5823ms} FormCanvas(Canvas)>>drawMorph: [ |8.8% {5823ms} FormCanvas(Canvas)>>draw: [ | 7.3% {4830ms} RectangleMorph(Morph)>>drawOn: [ | 6.4% {4235ms} FormCanvas(Canvas)>>fillRectangle:fillStyle:borderStyle: [ | 2.5% {1654ms} SimpleBorder>>frameRectangle:on: [ | |2.4% {1588ms} FormCanvas>>frameAndFillRectangle:fi...Color:bottomRightColor: [ | 2.1% {1390ms} FormCanvas>>fillRectangle:fillStyle: [ 6.2% {4103ms} TransformMorph>>drawSubmorphsOn: [ 5.7% {3772ms} FormCanvas(Canvas)>>fullDrawMorph: [ 5.4% {3573ms} FormCanvas(Canvas)>>fullDraw: [ 5.3% {3507ms} StringMorph(Morph)>>fullDrawOn: [ 2.7% {1787ms} FormCanvas(Canvas)>>drawMorph: [ 2.7% {1787ms} FormCanvas(Canvas)>>draw: [ 2.7% {1787ms} StringMorph>>drawOn: [ 2.6% {1720ms} FormCanvas(Canvas)>>drawString:in:font:color: [ 2.6% {1720ms} FormCanvas>>drawString:from:to:in:font:color: | | | | 10.4% {6882ms} FormCanvas(Canvas)>>drawMorph: | | | | 10.4% {6882ms} FormCanvas(Canvas)>>draw: | | | | 3.3% {2184ms} MenuItemMorph>>drawOn: [2.9% {1919ms} MenuItemMorph(StringMorph)>>drawOn: [ 2.9% {1919ms} FormCanvas(Canvas)>>drawString:in:font:color: [ 2.9% {1919ms} FormCanvas>>drawString:from:to:in:font:color: | | | | 2.3% {1522ms} ProjectViewMorph>>drawOn: | | | | 2.1% {1390ms} PluggableListMorph>>drawOn: | | | 3.7% {2448ms} FormCanvas(Canvas)>>drawMorph: | | | 3.7% {2448ms} FormCanvas(Canvas)>>draw: | | | 2.7% {1787ms} SystemWindow(Morph)>>drawOn: | | | 2.6% {1720ms} FormCanvas(Canvas)>>fillRectangle:fillStyle:borderStyle: | | 9.6% {6352ms} WorldState>>forceDamageToScreen: | | 9.6% {6352ms} DisplayScreen>>forceDamageToScreen: | | 9.5% {6286ms} DisplayScreen>>forceToScreen: | 3.1% {2051ms} HandMorph>>processEvents | 3.0% {1985ms} EventSensor>>nextEvent | 3.0% {1985ms} EventSensor>>nextEventFromQueue 18.0% {11911ms} MenuMorph>>popUpAt:forHand:in: |17.9% {11844ms} MenuMorph>>popUpAt:forHand:in:allowKeyboard: | 15.7% {10389ms} PasteUpMorph>>addMorphFront: | 15.7% {10389ms} PasteUpMorph(Morph)>>addMorphInFrontOfLayer: | 15.7% {10389ms} PasteUpMorph(Morph)>>addMorph:inFrontOf: | 15.7% {10389ms} PasteUpMorph(Morph)>>privateAddMorph:atIndex: | 15.4% {10190ms} PasteUpMorph(Morph)>>addedOrRemovedSubmorph: | 15.4% {10190ms} MenuMorph(Morph)>>fullBounds | 15.4% {10190ms} MenuMorph(Morph)>>doLayoutIn: | 13.7% {9065ms} TableLayout>>layout:in: | 13.7% {9065ms} TableLayout>>layoutTopToBottom:in: | 8.6% {5691ms} MenuItemMorph(Morph)>>layoutInBounds: | |5.1% {3375ms} MenuItemMorph(Morph)>>bounds: | | 2.7% {1787ms} MenuItemMorph(Morph)>>extent: | | |2.5% {1654ms} MenuItemMorph(Morph)>>changed | | | 2.1% {1390ms} MenuItemMorph(Morph)>>invalidRect: | | | 2.1% {1390ms} MenuItemMorph(Morph)>>invalidRect:from: | | 2.3% {1522ms} MenuItemMorph(Morph)>>position: | 4.2% {2779ms} MenuItemMorph(Morph)>>minExtent 5.1% {3375ms} PluggableListMorph>>getMenu: 5.1% {3375ms} PluggableListMorph(ScrollPane)>>getMenu: **Leaves** 9.5% {6286ms} DisplayScreen>>forceToScreen: 7.0% {4632ms} GrafPort>>copyBits 5.7% {3772ms} GrafPort(BitBlt)>>displayString:from:to:at:strikeFont:kern: 4.6% {3044ms} IdentityDictionary>>scanFor: 3.5% {2316ms} Point>>+ 3.5% {2316ms} Rectangle class>>origin:corner: 3.0% {1985ms} EventSensor>>nextEventFromQueue 2.5% {1654ms} Form>>copyBits:from:at:clippingBox:rule:fillColor:map: 2.2% {1456ms} SmallInteger class(Behavior)>>inheritsFrom: 2.2% {1456ms} IdentityDictionary(Dictionary)>>at:ifAbsent:
**Memory** old +194,044 bytes young -98,752 bytes used +95,292 bytes free -95,292 bytes
**GCs** full 0 totalling 0ms (0.0% uptime) incr 328 totalling 4,470ms (7.0% uptime), avg 14.0ms tenures 4 (avg 82 GCs/tenure) root table 0 overflows
As you can see, its pretty slow - 66 seconds! Some observations - corner rouding is turned off, so I'm a bit surprised to see CornerRounder in there. #forceToScreen: is a big hit because I can't get it (in the vm) to work without looking for all events (it should work, but it just won't.) TableLayout? in a menu?
tim
Tim,
As you can see, its pretty slow - 66 seconds! Some observations - corner rouding is turned off, so I'm a bit surprised to see CornerRounder in there.
Hm ... did you check to see if your menus have rounded corners?! ;-) It may also be the case that some other morph just ignores the preference.
#forceToScreen: is a big hit because I can't get it (in the vm) to work without looking for all events (it should work, but it just won't.)
Well, that's kinda okay - after all it got some "real work" to do here. Although it may mean that the invalidated regions are too large (e.g., damage recorder inefficiencies).
TableLayout? in a menu?
See my reply to Ned's message.
Cheers, - Andreas
"Andreas Raab" Andreas.Raab@gmx.de is claimed by the authorities to have written:
Tim,
As you can see, its pretty slow - 66 seconds! Some observations - corner rouding is turned off, so I'm a bit surprised to see CornerRounder in there.
Hm ... did you check to see if your menus have rounded corners?! ;-) It may also be the case that some other morph just ignores the preference.
I think it must be the annotation/button pane in the middle of the browser; those buttons (browse, senders, implementors etc) are rounded. Assuming, opf course, that they use CornerRounder. Which would actually strike me as a bit silly, to be honest.
tim
Mm on a 3.2.7b6 vm on a 500Mhz powerbook - 476 tallies, 8803 msec.
**Tree** 81.3% {7157ms} PasteUpMorph>>doOneCycleNow |81.3% {7157ms} WorldState>>doOneCycleNowFor: | 80.0% {7042ms} WorldState>>displayWorldSafely: | 80.0% {7042ms} PasteUpMorph>>displayWorld | 80.0% {7042ms} PasteUpMorph>>privateOuterDisplayWorld | 80.0% {7042ms} WorldState>>displayWorld:submorphs: | 66.6% {5863ms} WorldState>>drawWorld:submorphs:invalidAreasOn: | |63.4% {5581ms} FormCanvas(Canvas)>>fullDrawMorph: | | 63.2% {5563ms} FormCanvas(Canvas)>>fullDraw: | | 62.6% {5511ms} MenuMorph(Morph)>>fullDrawOn: | | 52.3% {4604ms} MenuMorph(Morph)>>drawSubmorphsOn: | | |52.3% {4604ms} FormCanvas(Canvas)>>fullDrawMorph: | | | 52.1% {4586ms} FormCanvas(Canvas)>>fullDraw: | | | 51.9% {4569ms} MenuLineMorph(Morph)>>fullDrawOn: | | | 40.1% {3530ms} PluggableTextMorph(Morph)>>drawSubmorphsOn: | | | |39.9% {3512ms} FormCanvas(Canvas)>>fullDrawMorph: | | | | 39.9% {3512ms} FormCanvas(Canvas)>>fullDraw: [39.9% {3512ms} RectangleMorph(Morph)>>fullDrawOn: [ 17.6% {1549ms} IconicButton(Morph)>>drawSubmorphsOn: [ |17.0% {1497ms} FormCanvas(Canvas)>>fullDrawMorph: [ | 16.6% {1461ms} FormCanvas(Canvas)>>fullDraw: [ | 16.4% {1444ms} SketchMorph(Morph)>>fullDrawOn: [ | 4.2% {370ms} PluggableButtonMorph(Morph)>>drawSubmorphsOn: [ | |4.2% {370ms} FormCanvas(Canvas)>>fullDrawMorph: [ | | 4.2% {370ms} FormCanvas(Canvas)>>fullDraw: [ | | 4.2% {370ms} AlignmentMorph(Morph)>>fullDrawOn: [ | 3.4% {299ms} FormCanvas(Canvas)>>drawMorph: [ | |3.4% {299ms} FormCanvas(Canvas)>>draw: [ | | 2.3% {202ms} RectangleMorph(Morph)>>drawOn: [ | | 2.3% {202ms} FormCanvas(Canvas)>>fillRectangle:fillStyle:borderStyle: [ | 3.2% {282ms} TransformMorph>>drawSubmorphsOn: [ | |3.2% {282ms} FormCanvas(Canvas)>>fullDrawMorph: [ | | 3.2% {282ms} FormCanvas(Canvas)>>fullDraw: [ | | 3.2% {282ms} TextMorphForEditView(Morph)>>fullDrawOn: [ | | 3.2% {282ms} FormCanvas(Canvas)>>drawMorph: [ | | 3.2% {282ms} FormCanvas(Canvas)>>draw: [ | | 2.7% {238ms} TextMorphForEditView(TextMorph)>>drawOn: [ | | 2.7% {238ms} FormCanvas>>paragraph:bounds:color: [ | | 2.7% {238ms} NewParagraph>>displayOn:using:at: [ | 3.2% {282ms} FormCanvas(Canvas)>>roundCornersOf:during: [ | 3.2% {282ms} FormCanvas>>roundCornersOf:in:during: [ | 2.9% {255ms} CornerRounder class>>roundCornersOf:on:i...orderWidth:corners: [ 9.5% {836ms} TransformMorph>>drawSubmorphsOn: [ |8.8% {775ms} FormCanvas(Canvas)>>fullDrawMorph: [ | 8.8% {775ms} FormCanvas(Canvas)>>fullDraw: [ | 8.8% {775ms} StringMorph(Morph)>>fullDrawOn: [ | 4.6% {405ms} FormCanvas(Canvas)>>drawMorph: [ | 4.6% {405ms} FormCanvas(Canvas)>>draw: [ | 2.7% {238ms} TextMorphForEditView(TextMorph)>>drawOn: [ | 2.5% {220ms} FormCanvas>>paragraph:bounds:color: [ | 2.3% {202ms} NewParagraph>>displayOn:using:at: [ | 2.3% {202ms} DisplayScanner>>displayLine:offset:leftInRun: [ 5.0% {440ms} FormCanvas(Canvas)>>roundCornersOf:during: [ |4.8% {423ms} FormCanvas>>roundCornersOf:in:during: [ | 4.0% {352ms} CornerRounder class>>roundCornersOf:on:i...orderWidth:corners: [ | 2.3% {202ms} CornerRounder>>tweakCornersOf:on:in:borderWidth:corners: [ 4.0% {352ms} FormCanvas(Canvas)>>drawMorph: [ 4.0% {352ms} FormCanvas(Canvas)>>draw: [ 3.4% {299ms} RectangleMorph(Morph)>>drawOn: [ 3.4% {299ms} FormCanvas(Canvas)>>fillRectangle:fillStyle:borderStyle: | | | 7.6% {669ms} FormCanvas(Canvas)>>drawMorph: | | | 7.4% {651ms} FormCanvas(Canvas)>>draw: | | | 2.5% {220ms} PluggableMessageCategoryListMorph(PluggableListMorph)>>drawOn: | | 5.3% {467ms} FormCanvas(Canvas)>>drawMorph: | | |5.3% {467ms} FormCanvas(Canvas)>>draw: | | | 4.0% {352ms} SystemWindow(Morph)>>drawOn: | | | 3.4% {299ms} FormCanvas(Canvas)>>fillRectangle:fillStyle:borderStyle: | | | 2.7% {238ms} RaisedBorder(SimpleBorder)>>frameRectangle:on: | | 4.4% {387ms} FormCanvas(Canvas)>>roundCornersOf:during: | | 4.4% {387ms} FormCanvas>>roundCornersOf:in:during: | | 4.0% {352ms} CornerRounder class>>roundCornersOf:on:i...orderWidth:corners: | | 2.7% {238ms} CornerRounder>>tweakCornersOf:on:in:borderWidth:corners: | 12.8% {1127ms} WorldState>>forceDamageToScreen: | 12.8% {1127ms} DisplayScreen>>forceDamageToScreen: | 12.8% {1127ms} DisplayScreen>>forceToScreen: 13.0% {1144ms} MenuMorph>>popUpAt:forHand:in: |13.0% {1144ms} MenuMorph>>popUpAt:forHand:in:allowKeyboard: | 11.8% {1039ms} PasteUpMorph>>addMorphFront: | 11.8% {1039ms} PasteUpMorph(Morph)>>addMorphInFrontOfLayer: | 11.8% {1039ms} PasteUpMorph(Morph)>>addMorph:inFrontOf: | 11.8% {1039ms} PasteUpMorph(Morph)>>privateAddMorph:atIndex: | 11.6% {1021ms} PasteUpMorph(Morph)>>addedOrRemovedSubmorph: | 11.6% {1021ms} MenuMorph(Morph)>>fullBounds | 11.6% {1021ms} MenuMorph(Morph)>>doLayoutIn: | 10.1% {889ms} TableLayout>>layout:in: | 10.1% {889ms} TableLayout>>layoutTopToBottom:in: | 7.8% {687ms} MenuItemMorph(Morph)>>layoutInBounds: | 6.1% {537ms} MenuItemMorph(Morph)>>bounds: | 3.2% {282ms} MenuItemMorph(Morph)>>extent: | 2.9% {255ms} MenuItemMorph(Morph)>>changed | 2.9% {255ms} MenuItemMorph(Morph)>>invalidRect: | 2.9% {255ms} MenuItemMorph(Morph)>>invalidRect:from: [2.7% {238ms} MenuMorph(Morph)>>invalidRect:from: 4.2% {370ms} PluggableListMorph>>getMenu: 4.2% {370ms} PluggableListMorph(ScrollPane)>>getMenu: **Leaves** 12.8% {1127ms} DisplayScreen>>forceToScreen: 4.0% {352ms} Rectangle>>top 3.4% {299ms} SmallInteger(Magnitude)>>max: 2.7% {238ms} IdentityDictionary>>scanFor: 2.5% {220ms} IdentityDictionary(Dictionary)>>at:ifAbsent: 2.5% {220ms} Form>>depth 2.3% {202ms} SmallInteger class(Behavior)>>inheritsFrom:
**Memory** old +91,648 bytes young +152,140 bytes used +243,788 bytes free -243,788 bytes
**GCs** full 0 totalling 0ms (0.0% uptime) incr 370 totalling 987ms (11.0% uptime), avg 3.0ms tenures 2 (avg 185 GCs/tenure) root table 0 overflows
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
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?
A very handy and intuitive tool for checking damage is #debugShowDamage, a preference which can be very simply enabled through the Preferences panel.
I turned it on and, sure enough, it immediately showed that every menu creation (from browser panes as well as the screen menu) is invalidating the top left corner of the screen (in exactly the shape of the menu). Depending what's in the top left of your screen, this could be a serious time waster.
- Dan
PS: Oh, yes... I checked a 2.8 Squeak and it does not exhibit this property (you have to edit the method for pasteUpMorph>>displayWorld, since debugShowDamage had not yet been made into a preference) and, yes, it feels a lot faster too.
Also, don't forget that morphic animation of dragged objects can be turned off on slow machines, etc.
Cheers,
Alan
-------
At 2:09 PM -0700 8/1/02, Tim Rowledge wrote:
In message <a05100307b96e66509feb@[10.0.0.2]> Bruce Cohen brucecohen@qwest.net wrote:
At 3:16 PM -0700 7/31/02, Tim Rowledge wrote:
b) that morphic is close to unusable on my pBook 400 OS-X machine and on my linux machine (p3/800 or something) these days.
Hmm ... I'm using 3.2 gamma with all updates on a 400 meg PowerBook OS X right now and doing almost nothing *but* Morphic programming. Its' not super-speedy, but performance is OK except when I try to run too many things at once (like putting "self halt" in a method that gets called every 20 milliseconds from a separate thread; very droll :-(. The one place where I would like more performance is when trying to playback a previously recorded event stream; sometimes the playback just can't keep up if there's something else going on. But that's also somewhat of an edge case. What performance problems are you seeing?
General tardiness in a non-descript way. I suspect that it's not so much Morphic qua Morphic, but inadequately optimised applications of it. For example, opening a menu in many browser places is taking maybe a quarter second, which might sound good but is actually almost perfectly irritating. Anything over 0.1 sec for something like that is just plain bad. On my Acorn machine for example, native menus typically appear about synchronously with the mouse button click reaching ones ear. Really! Remember, this is a _slow_ machine as well.
I suppose we really need some good meaningful test scenarios that can be automated and profiled to really try to sort this out. Then we could find out where the time is really going and do something about it. It wouldn't shock me to find out that somethings are being done two or more times instead of once, for example. Some sensible caching might prove useful.
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Machine independent code isn't.
--
Hi Scott--
I use MVC in Squeak 2.7, for running the interpreter simulator. As I recall, the interpreter simulator is broken in later releases. I also use MVC in a variety of releases (including the latest one) on handhelds when I need a bit more UI speed. I'll stop using releases earlier than 3.2 when the simulator works there, but I'd always like the option of running MVC (e.g., as a loadable module), if only for historical interest.
thanks,
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]
Craig Latta craig.latta@netjam.org wrote...
I use MVC in Squeak 2.7, for running the interpreter simulator. As I recall, the interpreter simulator is broken in later releases.
Awk! This is terrible news (but thanks for it!).
I also use MVC in a variety of releases (including the latest one) on handhelds when I need a bit more UI speed. I'll stop using releases earlier than 3.2 when the simulator works there, but I'd always like the option of running MVC (e.g., as a loadable module), if only for historical interest.
If folks will help me out a bit, I'll do all I can to get the simulator fixed in 3.2 asap (I know it's final, but it has an update stream ;-).
If it don't run itself, it ain't Squeak.
- Dan
Dan Ingalls Dan@SqueakLand.org is claimed by the authorities to have written:
Craig Latta craig.latta@netjam.org wrote...
I use MVC in Squeak 2.7, for running the interpreter simulator. As I recall, the interpreter simulator is broken in later releases.
Awk! This is terrible news (but thanks for it!). From being sat next to Craig during various attempts, I remember that a
large fraction of the problem relates to the complicated state of the startup process these days. Several plugins are invoked that do not have functional simulation code to suport them. Can't recall which but I'll bet Craig has a changelog of the hacks we tried to work around them. Basically there is simply too much cruft involved in the current image.
tim
I use MVC in Squeak 2.7, for running the interpretersimulator. As I recall, the interpreter simulator is broken in later releases.
Awk! This is terrible news (but thanks for it!).
Sure... 'Sorry, I thought you were aware of that; I mentioned this in the little how-to-run-the-simulator message I posted on 8 May (http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-May/014003.html). I guess I should have put [BUG] in the subject line... oops.
Anthony said he got it working in 3.2 shortly thereafter (http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-May/014129.html), so hopefully it won't be much to get the happiness bits into the update stream. :) Those fixes didn't make everything work for me, but I haven't spent much time on it yet.
-C
-- Craig Latta improvisational musical informaticist craig@netjam.org www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]
Hmph. I've never noticed it before, though that doesn't prove it hasn't happened of course, but after filing Scotts debugger related fix (3.2 release image, with Kom & seaside) any seaside related notifiers end up at the back of the window stack.
And to cap it all I currently have a locked up image for no reason I can make out right now. Foo. Oh, it's still responding perfectly well to seaside web-browser input...
sigh.
tim
Dan Ingalls wrote:
Scott Wallace scott.wallace@squeakland.org asked...
It seems to me that no Squeaker could plausibly have been doing
any real work in MVC in any 3.2 or 3.3a since this bug arrived more than eight months ago, because the mere raising of a single debugger would have put his environment into a state no reasonable person could tolerate. And he would therefore have screamed and we would have heard.
Having checked the stamps in my changesets, I can say I've been flipping between Morphic and MVC projects in 3.2a4586 (i.e., after the 4487 cs) last December. There were some text display issues in 1-bit mode that I recall; but indeed I may have performed most development work in Morphic, and only occasionally switched to the MVC project. Could very well be that I never actually *proceeded* through a notifier there...
Consequently, I'm not too surprised that there has not been a
single response posted to this thread, other than Boris's original bug report and my reply.
Sorry -- I saw it, but couldn't reply. (I have a hard time following *some* of SqueakML at all these days.)
But is it really true that there are actually *no* MVC
practitioners using either Squeak 3.2 or 3.3a , no one at all, except Boris?
My other MVC platform (that hasn't received much attention either lately) is the iPAQ with 3.0f3552 and 3.1a4332.
So if you are or might be an MVC user, in addition to answering Scott, please say...
What release do you use now? Do you plan to move to 3.2 in the near future?
I *have* 3.2f (on OSX) now, but have recently switched machines and haven't filed in or continued my projects yet. I *am* grateful for the workaround that Scott posted.
HTH, Helge
On Wed, 31 Jul 2002, Scott Wallace wrote:
But is it really true that there are actually *no* MVC practitioners using either Squeak 3.2 or 3.3a , no one at all, except Boris?
What reasons would an MVCer have to move to a newer version? With the exception of modules in 3.3a, almost everything being done in Squeak versions newer than maybe 2.6 (maybe farther back?) have to do with improvements/additions to Morphic or tools with Morphic-only interfaces. There hasn't been much in the way of enhancements to the core or super new libraries, &c. I may be wrong, but this is what i've noticed.
Regards, Aaron
On Wednesday 31 July 2002 03:21 pm, Aaron wrote:
On Wed, 31 Jul 2002, Scott Wallace wrote:
But is it really true that there are actually *no* MVC practitioners using either Squeak 3.2 or 3.3a , no one at all, except Boris?
What reasons would an MVCer have to move to a newer version? With the exception of modules in 3.3a, almost everything being done in Squeak versions newer than maybe 2.6 (maybe farther back?) have to do with improvements/additions to Morphic or tools with Morphic-only interfaces. There hasn't been much in the way of enhancements to the core or super new libraries, &c. I may be wrong, but this is what i've noticed.
There are a number of enhancements and bug fixes to the tools.The Process Browser runs under MVC. The FileList has been improved. There are improvements to the basic classes (Async file support, exceptions (a biggie), etc., etc.)
Some of the new Morphic tools (like the ArchiveViewer) will run in MVC; so unless you've actually gotten rid of Morphic, you can use them too.
I use MVC for development on my NEC MobilePro 770 (131MHz MIPS) since I find Morphic to be very slow on it.
squeak-dev@lists.squeakfoundation.org
-
Aaron -
Alan Kay -
Andreas Raab -
Boris Gaertner -
Bruce Cohen -
Craig Latta -
Dan Ingalls -
David Farber -
Göran Hultgren -
Helge.Horch＠t-online.de -
John M McIntosh -
Ned Konz -
Scott A Crosby -
Scott Wallace -
Tim Rowledge