[Pharo-project] Morph extension
henrik.s.johansen at veloxit.no
Tue Sep 8 14:01:58 EDT 2009
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
>> window operations when fillStyle; borderStyle; hResizing; vResizing
>> made as instance variables of Morph, rather than going through
> 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 := 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;
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)
[rest below 5000 accesses]
More information about the Pharo-dev