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