[Pharo-project] Morph extension
After some experimenting I can get over 10% perfromance improvement with window operations when fillStyle; borderStyle; hResizing; vResizing are made as instance variables of Morph, rather than going through extension. I thought Marcus has mentioned this some time ago, but no progress? There is obviously an issue with name collision/shadowing but not many methods in core need changing to accomodate. Whilst on the subject I am wondering on everyone's opinion on merging the behaviour of color/borderColor/borderWidth with that of fillStyle... sure to be some gains there! Regards, Gary
On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote:
After some experimenting I can get over 10% perfromance improvement with window operations when fillStyle; borderStyle; hResizing; vResizing are made as instance variables of Morph, rather than going through extension.
this is a lot. You really mean Morph or we could get them in subclasses too.
I thought Marcus has mentioned this some time ago, but no progress?
No progress just playing with it at esug last year.
There is obviously an issue with name collision/shadowing but not many methods in core need changing to accomodate.
Whilst on the subject I am wondering on everyone's opinion on merging the behaviour of color/borderColor/borderWidth with that of fillStyle... sure to be some gains there!
Regards, Gary _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Affects the performance of all Morph (and subclass) instances. Regards, Gary ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, September 08, 2009 5:49 PM Subject: Re: [Pharo-project] Morph extension
On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote:
After some experimenting I can get over 10% perfromance improvement with window operations when fillStyle; borderStyle; hResizing; vResizing are made as instance variables of Morph, rather than going through extension.
this is a lot. You really mean Morph or we could get them in subclasses too.
I thought Marcus has mentioned this some time ago, but no progress?
No progress just playing with it at esug last year.
There is obviously an issue with name collision/shadowing but not many methods in core need changing to accomodate.
Whilst on the subject I am wondering on everyone's opinion on merging the behaviour of color/borderColor/borderWidth with that of fillStyle... sure to be some gains there!
Regards, Gary _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse skrev:
On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote:
After some experimenting I can get over 10% perfromance improvement with window operations when fillStyle; borderStyle; hResizing; vResizing are made as instance variables of Morph, rather than going through extension.
this is a lot. You really mean Morph or we could get them in subclasses too.
Inspect this in an image with some windows open, it will give you the percentage of morphs with otherProperties containing any given property: |propBag noMorphs| propBag := Bag new: 50. noMorphs := 0. Morph allSubInstances do: [:each | each otherProperties ifNotNil: [:props | propBag addAll: props keys. noMorphs := noMorphs +1]] . noMorphs := noMorphs asFloat. propBag sortedCounts collect: [:each | each key: each key / noMorphs; yourself] otherProperties is heavily abused. with respectively 98 and 125 senders of valueOfProperty: / valueOfProperty:ifAbsent:... In my case there were _57_ different distinct otherProperties in use, an average of three, a maximum of 15, and four of them present in over a quarter of morphs defining any (80% for the most common one)... If moving directly to Morph is a bit extreme, at least _some_ of these qualify for promotion to direct access in MorphExtension imho, it seems to have some "free" instvars anyways after the removal of players. In the interest of seeing which would benefit the most from moving, I did a small profile: - Dragging a window and switching some between different ones with 2 browsers, a monticello browser, a workspace and a Method search open. I had the following access numbers: 105586->#clipSubmorphs (about 4.5 per millisecond) 66029->#layoutProperties 62783->#layoutPolicy 55556->#theme 41312->#hasDropShadow 41310->#hasRolloverBorder 36817->#fillStyle 19241->#cornerStyle 13239->#highlightedForDrop 13239->#highlightedForMouseDown 11945->#roundedCorners 11911->#borderStyle 10644->#edgeToAdhereTo 9020->#paneColor 8885->#lastPaneColor [rest below 5000 accesses] Cheers, Henry
I get a different "top offenders" list of course. I've managed to refactor the worst offenders. Benchmarks for the "opening system browser" below show an improvement. Going from patched to unpatched shows that the unpatched takes between 15% and 20% longer to complete depending on fonts/theme. (Benchmark code) | saveMorphs time | [saveMorphs := World submorphs. World removeAllMorphs."heh, heh" time := [1 to: 10 do: [:i | MorphicToolBuilder new open: (Browser new setClass: SystemDictionary selector: nil). World doOneCycleNow]. World submorphs do: [:m | m delete. World doOneCycleNow]. ] timeToRun] ensure:[World addAllMorphs: saveMorphs]. SystemWindow noteTopWindowIn: World. time (end of benchmark code) I can make a changeset available for the brave who want to try. I have developed a workspace script that (finally) appears to load it correctly, waas a lot of hung-image before getting there... (loading tested on 10451-BETA) Regards, Gary ----- Original Message ----- From: "Henrik Johansen" <henrik.s.johansen@veloxit.no> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, September 08, 2009 7:01 PM Subject: Re: [Pharo-project] Morph extension Stéphane Ducasse skrev:
On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote:
After some experimenting I can get over 10% perfromance improvement with window operations when fillStyle; borderStyle; hResizing; vResizing are made as instance variables of Morph, rather than going through extension.
this is a lot. You really mean Morph or we could get them in subclasses too.
Inspect this in an image with some windows open, it will give you the percentage of morphs with otherProperties containing any given property: |propBag noMorphs| propBag := Bag new: 50. noMorphs := 0. Morph allSubInstances do: [:each | each otherProperties ifNotNil: [:props | propBag addAll: props keys. noMorphs := noMorphs +1]] . noMorphs := noMorphs asFloat. propBag sortedCounts collect: [:each | each key: each key / noMorphs; yourself] otherProperties is heavily abused. with respectively 98 and 125 senders of valueOfProperty: / valueOfProperty:ifAbsent:... In my case there were _57_ different distinct otherProperties in use, an average of three, a maximum of 15, and four of them present in over a quarter of morphs defining any (80% for the most common one)... If moving directly to Morph is a bit extreme, at least _some_ of these qualify for promotion to direct access in MorphExtension imho, it seems to have some "free" instvars anyways after the removal of players. In the interest of seeing which would benefit the most from moving, I did a small profile: - Dragging a window and switching some between different ones with 2 browsers, a monticello browser, a workspace and a Method search open. I had the following access numbers: 105586->#clipSubmorphs (about 4.5 per millisecond) 66029->#layoutProperties 62783->#layoutPolicy 55556->#theme 41312->#hasDropShadow 41310->#hasRolloverBorder 36817->#fillStyle 19241->#cornerStyle 13239->#highlightedForDrop 13239->#highlightedForMouseDown 11945->#roundedCorners 11911->#borderStyle 10644->#edgeToAdhereTo 9020->#paneColor 8885->#lastPaneColor [rest below 5000 accesses] Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 16.09.2009, at 10:29, Gary Chambers wrote:
I get a different "top offenders" list of course. I've managed to refactor the worst offenders.
Benchmarks for the "opening system browser" below show an improvement.
Going from patched to unpatched shows that the unpatched takes between 15% and 20% longer to complete depending on fonts/theme.
(Benchmark code)
| saveMorphs time | [saveMorphs := World submorphs. World removeAllMorphs."heh, heh" time := [1 to: 10 do: [:i | MorphicToolBuilder new open: (Browser new setClass: SystemDictionary selector: nil). World doOneCycleNow]. World submorphs do: [:m | m delete. World doOneCycleNow]. ] timeToRun] ensure:[World addAllMorphs: saveMorphs]. SystemWindow noteTopWindowIn: World. time
(end of benchmark code)
I can make a changeset available for the brave who want to try.
Yes, I would like to try! Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Me too! Both actorState and player in MorphExtension are now unused btw, if you decided to put them there you might as well remove those two at the same time :) Cheers, Henry On Sep 16, 2009, at 4:43 43PM, Marcus Denker wrote:
On 16.09.2009, at 10:29, Gary Chambers wrote:
I get a different "top offenders" list of course. I've managed to refactor the worst offenders.
Benchmarks for the "opening system browser" below show an improvement.
Going from patched to unpatched shows that the unpatched takes between 15% and 20% longer to complete depending on fonts/theme.
(Benchmark code)
| saveMorphs time | [saveMorphs := World submorphs. World removeAllMorphs."heh, heh" time := [1 to: 10 do: [:i | MorphicToolBuilder new open: (Browser new setClass: SystemDictionary selector: nil). World doOneCycleNow]. World submorphs do: [:m | m delete. World doOneCycleNow]. ] timeToRun] ensure:[World addAllMorphs: saveMorphs]. SystemWindow noteTopWindowIn: World. time
(end of benchmark code)
I can make a changeset available for the brave who want to try.
Yes, I would like to try!
Marcus
-- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hopefully I've not missed anything... I have noticed that a fileout from the change sorter doesn't appear to write out any methods that are in *-override categories... at least that's how it seems (might be another problem!). Regards, Gary ----- Original Message ----- From: "Henrik Johansen" <henrik.s.johansen@veloxit.no> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, September 16, 2009 3:56 PM Subject: Re: [Pharo-project] Morph extension
Me too! Both actorState and player in MorphExtension are now unused btw, if you decided to put them there you might as well remove those two at the same time :)
Cheers, Henry
On Sep 16, 2009, at 4:43 43PM, Marcus Denker wrote:
On 16.09.2009, at 10:29, Gary Chambers wrote:
I get a different "top offenders" list of course. I've managed to refactor the worst offenders.
Benchmarks for the "opening system browser" below show an improvement.
Going from patched to unpatched shows that the unpatched takes between 15% and 20% longer to complete depending on fonts/theme.
(Benchmark code)
| saveMorphs time | [saveMorphs := World submorphs. World removeAllMorphs."heh, heh" time := [1 to: 10 do: [:i | MorphicToolBuilder new open: (Browser new setClass: SystemDictionary selector: nil). World doOneCycleNow]. World submorphs do: [:m | m delete. World doOneCycleNow]. ] timeToRun] ensure:[World addAllMorphs: saveMorphs]. SystemWindow noteTopWindowIn: World. time
(end of benchmark code)
I can make a changeset available for the brave who want to try.
Yes, I would like to try!
Marcus
-- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Gary I would love to see morphic goes faster so we are ready to try :) Stef
I've managed to refactor the worst offenders.
Benchmarks for the "opening system browser" below show an improvement.
Going from patched to unpatched shows that the unpatched takes between 15% and 20% longer to complete depending on fonts/theme.
(Benchmark code)
| saveMorphs time | [saveMorphs := World submorphs. World removeAllMorphs."heh, heh" time := [1 to: 10 do: [:i | MorphicToolBuilder new open: (Browser new setClass: SystemDictionary selector: nil). World doOneCycleNow]. World submorphs do: [:m | m delete. World doOneCycleNow]. ] timeToRun] ensure:[World addAllMorphs: saveMorphs]. SystemWindow noteTopWindowIn: World. time
(end of benchmark code)
I can make a changeset available for the brave who want to try. I have developed a workspace script that (finally) appears to load it correctly, waas a lot of hung-image before getting there...
(loading tested on 10451-BETA)
Regards, Gary
----- Original Message ----- From: "Henrik Johansen" <henrik.s.johansen@veloxit.no> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, September 08, 2009 7:01 PM Subject: Re: [Pharo-project] Morph extension
Stéphane Ducasse skrev:
On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote:
After some experimenting I can get over 10% perfromance improvement with window operations when fillStyle; borderStyle; hResizing; vResizing are made as instance variables of Morph, rather than going through extension.
this is a lot. You really mean Morph or we could get them in subclasses too.
Inspect this in an image with some windows open, it will give you the percentage of morphs with otherProperties containing any given property:
|propBag noMorphs| propBag := Bag new: 50. noMorphs := 0. Morph allSubInstances do: [:each | each otherProperties ifNotNil: [:props | propBag addAll: props keys. noMorphs := noMorphs +1]] . noMorphs := noMorphs asFloat. propBag sortedCounts collect: [:each | each key: each key / noMorphs; yourself]
otherProperties is heavily abused. with respectively 98 and 125 senders of valueOfProperty: / valueOfProperty:ifAbsent:... In my case there were _57_ different distinct otherProperties in use, an average of three, a maximum of 15, and four of them present in over a quarter of morphs defining any (80% for the most common one)... If moving directly to Morph is a bit extreme, at least _some_ of these qualify for promotion to direct access in MorphExtension imho, it seems to have some "free" instvars anyways after the removal of players.
In the interest of seeing which would benefit the most from moving, I did a small profile: - Dragging a window and switching some between different ones with 2 browsers, a monticello browser, a workspace and a Method search open. I had the following access numbers: 105586->#clipSubmorphs (about 4.5 per millisecond) 66029->#layoutProperties 62783->#layoutPolicy 55556->#theme 41312->#hasDropShadow 41310->#hasRolloverBorder 36817->#fillStyle 19241->#cornerStyle 13239->#highlightedForDrop 13239->#highlightedForMouseDown 11945->#roundedCorners 11911->#borderStyle 10644->#edgeToAdhereTo 9020->#paneColor 8885->#lastPaneColor [rest below 5000 accesses]
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Have a go with it (use a fresh image rather than anything you might want to lose...). Stick the .cs in your image directory, open a workspace and do the following... (FileStream readOnlyFileNamed: 'MorphicExtensionPerformance.1.cs') fileInSilentlyAnnouncing: nil. Morph allSubInstances do: [:m | #(fillStyle layoutPolicy layoutFrame layoutProperties borderStyle cornerStyle actionMap clipSubmorphs) do: [:prop | m extension ifNotNilDo: [:extension | extension otherProperties ifNotNilDo: [:otherProperties | extension instVarNamed: prop put: ( otherProperties at: prop ifAbsent: []). otherProperties removeKey: #prop ifAbsent: []]]]] Regards, Gary ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, September 16, 2009 3:49 PM Subject: Re: [Pharo-project] Morph extension Gary I would love to see morphic goes faster so we are ready to try :) Stef
I've managed to refactor the worst offenders.
Benchmarks for the "opening system browser" below show an improvement.
Going from patched to unpatched shows that the unpatched takes between 15% and 20% longer to complete depending on fonts/theme.
(Benchmark code)
| saveMorphs time | [saveMorphs := World submorphs. World removeAllMorphs."heh, heh" time := [1 to: 10 do: [:i | MorphicToolBuilder new open: (Browser new setClass: SystemDictionary selector: nil). World doOneCycleNow]. World submorphs do: [:m | m delete. World doOneCycleNow]. ] timeToRun] ensure:[World addAllMorphs: saveMorphs]. SystemWindow noteTopWindowIn: World. time
(end of benchmark code)
I can make a changeset available for the brave who want to try. I have developed a workspace script that (finally) appears to load it correctly, waas a lot of hung-image before getting there...
(loading tested on 10451-BETA)
Regards, Gary
----- Original Message ----- From: "Henrik Johansen" <henrik.s.johansen@veloxit.no> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, September 08, 2009 7:01 PM Subject: Re: [Pharo-project] Morph extension
Stéphane Ducasse skrev:
On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote:
After some experimenting I can get over 10% perfromance improvement with window operations when fillStyle; borderStyle; hResizing; vResizing are made as instance variables of Morph, rather than going through extension.
this is a lot. You really mean Morph or we could get them in subclasses too.
Inspect this in an image with some windows open, it will give you the percentage of morphs with otherProperties containing any given property:
|propBag noMorphs| propBag := Bag new: 50. noMorphs := 0. Morph allSubInstances do: [:each | each otherProperties ifNotNil: [:props | propBag addAll: props keys. noMorphs := noMorphs +1]] . noMorphs := noMorphs asFloat. propBag sortedCounts collect: [:each | each key: each key / noMorphs; yourself]
otherProperties is heavily abused. with respectively 98 and 125 senders of valueOfProperty: / valueOfProperty:ifAbsent:... In my case there were _57_ different distinct otherProperties in use, an average of three, a maximum of 15, and four of them present in over a quarter of morphs defining any (80% for the most common one)... If moving directly to Morph is a bit extreme, at least _some_ of these qualify for promotion to direct access in MorphExtension imho, it seems to have some "free" instvars anyways after the removal of players.
In the interest of seeing which would benefit the most from moving, I did a small profile: - Dragging a window and switching some between different ones with 2 browsers, a monticello browser, a workspace and a Method search open. I had the following access numbers: 105586->#clipSubmorphs (about 4.5 per millisecond) 66029->#layoutProperties 62783->#layoutPolicy 55556->#theme 41312->#hasDropShadow 41310->#hasRolloverBorder 36817->#fillStyle 19241->#cornerStyle 13239->#highlightedForDrop 13239->#highlightedForMouseDown 11945->#roundedCorners 11911->#borderStyle 10644->#edgeToAdhereTo 9020->#paneColor 8885->#lastPaneColor [rest below 5000 accesses]
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi, I added an entry in the bugtracker (tagged 1.1), so we can have a look a this during the sprint in Lille. http://code.google.com/p/pharo/issues/detail?id=1254 On 16.09.2009, at 10:55, Gary Chambers wrote:
Have a go with it (use a fresh image rather than anything you might want to lose...). Stick the .cs in your image directory, open a workspace and do the following...
(FileStream readOnlyFileNamed: 'MorphicExtensionPerformance.1.cs') fileInSilentlyAnnouncing: nil. Morph allSubInstances do: [:m | #(fillStyle layoutPolicy layoutFrame layoutProperties borderStyle cornerStyle actionMap clipSubmorphs) do: [:prop | m extension ifNotNilDo: [:extension | extension otherProperties ifNotNilDo: [:otherProperties | extension instVarNamed: prop put: ( otherProperties at: prop ifAbsent: []). otherProperties removeKey: #prop ifAbsent: []]]]]
Regards, Gary
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr
To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, September 16, 2009 3:49 PM Subject: Re: [Pharo-project] Morph extension
Gary I would love to see morphic goes faster so we are ready to try :)
Stef
I've managed to refactor the worst offenders.
Benchmarks for the "opening system browser" below show an improvement.
Going from patched to unpatched shows that the unpatched takes between 15% and 20% longer to complete depending on fonts/theme.
(Benchmark code)
| saveMorphs time | [saveMorphs := World submorphs. World removeAllMorphs."heh, heh" time := [1 to: 10 do: [:i | MorphicToolBuilder new open: (Browser new setClass: SystemDictionary selector: nil). World doOneCycleNow]. World submorphs do: [:m | m delete. World doOneCycleNow]. ] timeToRun] ensure:[World addAllMorphs: saveMorphs]. SystemWindow noteTopWindowIn: World. time
(end of benchmark code)
I can make a changeset available for the brave who want to try. I have developed a workspace script that (finally) appears to load it correctly, waas a lot of hung-image before getting there...
(loading tested on 10451-BETA)
Regards, Gary
----- Original Message ----- From: "Henrik Johansen" <henrik.s.johansen@veloxit.no> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, September 08, 2009 7:01 PM Subject: Re: [Pharo-project] Morph extension
Stéphane Ducasse skrev:
On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote:
After some experimenting I can get over 10% perfromance improvement with window operations when fillStyle; borderStyle; hResizing; vResizing are made as instance variables of Morph, rather than going through extension.
this is a lot. You really mean Morph or we could get them in subclasses too.
Inspect this in an image with some windows open, it will give you the percentage of morphs with otherProperties containing any given property:
|propBag noMorphs| propBag := Bag new: 50. noMorphs := 0. Morph allSubInstances do: [:each | each otherProperties ifNotNil: [:props | propBag addAll: props keys. noMorphs := noMorphs +1]] . noMorphs := noMorphs asFloat. propBag sortedCounts collect: [:each | each key: each key / noMorphs; yourself]
otherProperties is heavily abused. with respectively 98 and 125 senders of valueOfProperty: / valueOfProperty:ifAbsent:... In my case there were _57_ different distinct otherProperties in use, an average of three, a maximum of 15, and four of them present in over a quarter of morphs defining any (80% for the most common one)... If moving directly to Morph is a bit extreme, at least _some_ of these qualify for promotion to direct access in MorphExtension imho, it seems to have some "free" instvars anyways after the removal of players.
In the interest of seeing which would benefit the most from moving, I did a small profile: - Dragging a window and switching some between different ones with 2 browsers, a monticello browser, a workspace and a Method search open. I had the following access numbers: 105586->#clipSubmorphs (about 4.5 per millisecond) 66029->#layoutProperties 62783->#layoutPolicy 55556->#theme 41312->#hasDropShadow 41310->#hasRolloverBorder 36817->#fillStyle 19241->#cornerStyle 13239->#highlightedForDrop 13239->#highlightedForMouseDown 11945->#roundedCorners 11911->#borderStyle 10644->#edgeToAdhereTo 9020->#paneColor 8885->#lastPaneColor [rest below 5000 accesses]
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project <MorphicExtensionPerformance. 1.cs>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
OOoohhh... I remember doing similar hacks in Squeak... it's been quite a while since I was familiar with the code, but I thought I'd mention this in case it helps. Today, I get the impression that, more than properties, what morphs need are policy objects. In that way, acting as a response to a property becomes an unconditional message send to a policy object (as opposed to retrieve + valueOrNil check + ifTrue:ifFalse: + and then do something). Particularly with a PIC-capable VM, this should speed up execution (even without PICs, I'd guess even an IC-capable VM should have no problem making this run reasonably fast). But... I am not that familiar with Morphic right now. Would policy objects be a good idea for today's state of affairs? Andres. Stéphane Ducasse wrote:
Gary I would love to see morphic goes faster so we are ready to try :)
Stef
I've managed to refactor the worst offenders.
Benchmarks for the "opening system browser" below show an improvement.
Going from patched to unpatched shows that the unpatched takes between 15% and 20% longer to complete depending on fonts/theme.
(Benchmark code)
| saveMorphs time | [saveMorphs := World submorphs. World removeAllMorphs."heh, heh" time := [1 to: 10 do: [:i | MorphicToolBuilder new open: (Browser new setClass: SystemDictionary selector: nil). World doOneCycleNow]. World submorphs do: [:m | m delete. World doOneCycleNow]. ] timeToRun] ensure:[World addAllMorphs: saveMorphs]. SystemWindow noteTopWindowIn: World. time
(end of benchmark code)
I can make a changeset available for the brave who want to try. I have developed a workspace script that (finally) appears to load it correctly, waas a lot of hung-image before getting there...
(loading tested on 10451-BETA)
Regards, Gary
----- Original Message ----- From: "Henrik Johansen" <henrik.s.johansen@veloxit.no> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, September 08, 2009 7:01 PM Subject: Re: [Pharo-project] Morph extension
Stéphane Ducasse skrev:
On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote:
After some experimenting I can get over 10% perfromance improvement with window operations when fillStyle; borderStyle; hResizing; vResizing are made as instance variables of Morph, rather than going through extension.
this is a lot. You really mean Morph or we could get them in subclasses too.
Inspect this in an image with some windows open, it will give you the percentage of morphs with otherProperties containing any given property:
|propBag noMorphs| propBag := Bag new: 50. noMorphs := 0. Morph allSubInstances do: [:each | each otherProperties ifNotNil: [:props | propBag addAll: props keys. noMorphs := noMorphs +1]] . noMorphs := noMorphs asFloat. propBag sortedCounts collect: [:each | each key: each key / noMorphs; yourself]
otherProperties is heavily abused. with respectively 98 and 125 senders of valueOfProperty: / valueOfProperty:ifAbsent:... In my case there were _57_ different distinct otherProperties in use, an average of three, a maximum of 15, and four of them present in over a quarter of morphs defining any (80% for the most common one)... If moving directly to Morph is a bit extreme, at least _some_ of these qualify for promotion to direct access in MorphExtension imho, it seems to have some "free" instvars anyways after the removal of players.
In the interest of seeing which would benefit the most from moving, I did a small profile: - Dragging a window and switching some between different ones with 2 browsers, a monticello browser, a workspace and a Method search open. I had the following access numbers: 105586->#clipSubmorphs (about 4.5 per millisecond) 66029->#layoutProperties 62783->#layoutPolicy 55556->#theme 41312->#hasDropShadow 41310->#hasRolloverBorder 36817->#fillStyle 19241->#cornerStyle 13239->#highlightedForDrop 13239->#highlightedForMouseDown 11945->#roundedCorners 11911->#borderStyle 10644->#edgeToAdhereTo 9020->#paneColor 8885->#lastPaneColor [rest below 5000 accesses]
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project .
In principle that is possible. Though Morph doesn't implement a "setter" for extension at the moment... There are, however, a lot of "default" value checks in Morph, likely due to the difficulty of migration in a live image environment. Regards, Gary ----- Original Message ----- From: "Andres Valloud" <avalloud@smalltalk.comcastbiz.net> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, September 16, 2009 3:56 PM Subject: Re: [Pharo-project] Morph extension OOoohhh... I remember doing similar hacks in Squeak... it's been quite a while since I was familiar with the code, but I thought I'd mention this in case it helps. Today, I get the impression that, more than properties, what morphs need are policy objects. In that way, acting as a response to a property becomes an unconditional message send to a policy object (as opposed to retrieve + valueOrNil check + ifTrue:ifFalse: + and then do something). Particularly with a PIC-capable VM, this should speed up execution (even without PICs, I'd guess even an IC-capable VM should have no problem making this run reasonably fast). But... I am not that familiar with Morphic right now. Would policy objects be a good idea for today's state of affairs? Andres. Stéphane Ducasse wrote:
Gary I would love to see morphic goes faster so we are ready to try :)
Stef
I've managed to refactor the worst offenders.
Benchmarks for the "opening system browser" below show an improvement.
Going from patched to unpatched shows that the unpatched takes between 15% and 20% longer to complete depending on fonts/theme.
(Benchmark code)
| saveMorphs time | [saveMorphs := World submorphs. World removeAllMorphs."heh, heh" time := [1 to: 10 do: [:i | MorphicToolBuilder new open: (Browser new setClass: SystemDictionary selector: nil). World doOneCycleNow]. World submorphs do: [:m | m delete. World doOneCycleNow]. ] timeToRun] ensure:[World addAllMorphs: saveMorphs]. SystemWindow noteTopWindowIn: World. time
(end of benchmark code)
I can make a changeset available for the brave who want to try. I have developed a workspace script that (finally) appears to load it correctly, waas a lot of hung-image before getting there...
(loading tested on 10451-BETA)
Regards, Gary
----- Original Message ----- From: "Henrik Johansen" <henrik.s.johansen@veloxit.no> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, September 08, 2009 7:01 PM Subject: Re: [Pharo-project] Morph extension
Stéphane Ducasse skrev:
On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote:
After some experimenting I can get over 10% perfromance improvement with window operations when fillStyle; borderStyle; hResizing; vResizing are made as instance variables of Morph, rather than going through extension.
this is a lot. You really mean Morph or we could get them in subclasses too.
Inspect this in an image with some windows open, it will give you the percentage of morphs with otherProperties containing any given property:
|propBag noMorphs| propBag := Bag new: 50. noMorphs := 0. Morph allSubInstances do: [:each | each otherProperties ifNotNil: [:props | propBag addAll: props keys. noMorphs := noMorphs +1]] . noMorphs := noMorphs asFloat. propBag sortedCounts collect: [:each | each key: each key / noMorphs; yourself]
otherProperties is heavily abused. with respectively 98 and 125 senders of valueOfProperty: / valueOfProperty:ifAbsent:... In my case there were _57_ different distinct otherProperties in use, an average of three, a maximum of 15, and four of them present in over a quarter of morphs defining any (80% for the most common one)... If moving directly to Morph is a bit extreme, at least _some_ of these qualify for promotion to direct access in MorphExtension imho, it seems to have some "free" instvars anyways after the removal of players.
In the interest of seeing which would benefit the most from moving, I did a small profile: - Dragging a window and switching some between different ones with 2 browsers, a monticello browser, a workspace and a Method search open. I had the following access numbers: 105586->#clipSubmorphs (about 4.5 per millisecond) 66029->#layoutProperties 62783->#layoutPolicy 55556->#theme 41312->#hasDropShadow 41310->#hasRolloverBorder 36817->#fillStyle 19241->#cornerStyle 13239->#highlightedForDrop 13239->#highlightedForMouseDown 11945->#roundedCorners 11911->#borderStyle 10644->#edgeToAdhereTo 9020->#paneColor 8885->#lastPaneColor [rest below 5000 accesses]
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project .
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Andres Valloud -
Gary Chambers -
Henrik Johansen -
Marcus Denker -
Stéphane Ducasse