Morph extension

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Morph extension

Gary Chambers-4
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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Morph extension

Stéphane Ducasse

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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Morph extension

Gary Chambers-4
Affects the performance of all Morph (and subclass) instances.

Regards, Gary

----- Original Message -----
From: "Stéphane Ducasse" <[hidden email]>
To: <[hidden email]>
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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Morph extension

Henrik Sperre Johansen
In reply to this post by Stéphane Ducasse


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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Morph extension

Gary Chambers-4
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" <[hidden email]>
To: <[hidden email]>
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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Morph extension

Marcus Denker-3

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Morph extension

Stéphane Ducasse
In reply to this post by Gary Chambers-4
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" <[hidden email]>
> To: <[hidden email]>
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Morph extension

Gary Chambers-4
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" <[hidden email]>
To: <[hidden email]>
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" <[hidden email]>
> To: <[hidden email]>
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

MorphicExtensionPerformance.1.cs (24K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Morph extension

Andres Valloud-4
In reply to this post by Stéphane Ducasse
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" <[hidden email]>
>> To: <[hidden email]>
>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>    
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> .
>
>  

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Morph extension

Henrik Sperre Johansen
In reply to this post by Marcus Denker-3
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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Morph extension

Gary Chambers-4
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" <[hidden email]>
To: <[hidden email]>
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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Morph extension

Gary Chambers-4
In reply to this post by Andres Valloud-4
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" <[hidden email]>
To: <[hidden email]>
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" <[hidden email]>
>> To: <[hidden email]>
>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> .
>
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Morph extension

Marcus Denker-3
In reply to this post by Gary Chambers-4
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" <[hidden email]
> >
> To: <[hidden email]>
> 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" <[hidden email]>
>> To: <[hidden email]>
>> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> <MorphicExtensionPerformance.
> 1.cs>_______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project