[ENH] submorphsCleanup-efc

Doug Way dway at mailcan.com
Mon Jul 25 19:07:32 UTC 2005


Sounds like a good idea to me, too... if it works, we could make using a
copy the exception rather than the rule.  E.g. change
PasteUpMorph>>imposeListViewSortingBy: to do "self submorphs copy",
which it seems like it probably should be doing.  I can't imagine there
are too many cases where a copy is really required.

I may try making this change in the image I regularly use also, to see
if anything starts breaking.

- Doug


On Sun, 24 Jul 2005 20:05:01 -0400, "Eddie Cottongim"
<cottonsqueak at earthlink.net> said:
> I think you are correct. I was afraid to try that, but if it's safe, I'd 
> like it a lot better than playing whack-a-mole with "submorphs size".
> 
> The only thing I can find to the contrary is this note from 
> PasteUpMorph>>imposeListViewSortingBy: retrieving:
> 
>     self submorphs "important that it be a copy" do:
>         [:aMorph |
>             rep _ aMorph listViewLineForFieldList: fieldListSelectors.
>             rep hResizing: #spaceFill.
>             self replaceSubmorph: aMorph by: rep].
> 
> But I think this will actually work either way. I can't seem to break 
> anything by deleting while iterating, which I thought might be a problem.
> 
> I'm trying it in my image now. Nothing has broken so far... But its not 
> easy to know all the paths are working right.
> 
> Thanks,
> Eddie
> 
> Andreas Raab wrote:
> 
> > Hi -
> >
> > Just out of curiosity: Have you considered simply not copying the 
> > submorphs? I have always wondered what would happen then - likely 
> > nothing since the submorphs are an array (e.g., essentially read-only) 
> > and I cannot remember any client using it in an otherwise problematic 
> > way.
> >
> > Cheers,
> >   - Andreas
> >
> > cottonsqueak at earthlink.net wrote:
> >
> >> from preamble:
> >>
> >> "Change Set:        submorphsCleanup-efc
> >> Date:            24 July 2005
> >> Author:            Eddie Cottongim
> >>
> >> In profiling for speed, I've noticed that a common culprit for poor
> >> scaling to large numbers of morphs is unnecessary use of #submorphs
> >> where the whole collection is not actually needed. There is often a
> >> trivial replacement that can spare doing the copy, and is probably
> >> better style. #copy is very fast, but it can introduce O(n*n)
> >> performance that is noticable when you have a lot of morphs, the machine
> >> is slow, or both. Also the callers tend to send #submorphs two or three
> >> times in one method!!
> >>
> >> I've gone through what looked like the core morphic classes and carried
> >> out transformations that looked trivial. I haven't touched more
> >> complicated cases. The ones I can't get without adding methods or
> >> rewriting the caller are the complicated Collection selectors that don't
> >> have a ready equivilent in Morph, and direct submorph access by index,
> >> which Morph doesn't have for some reason.
> >>  
> >> The following conversions have been made:
> >>
> >> submorphs size -> submorphCount
> >> submorphs do: -> submorphsDo:
> >> submorphs last -> lastSubmorph
> >> submorphs first -> firstSubmorph
> >> submorphs empty -> (not)hasSubmorphs
> >> submorphs indexOf: -> submorphsIndexOf:
> >>
> >> Those on very slow machines may see some benefit from this in normal
> >> use. Others may only benefit in extreme cases with a LOT of Morphs.
> >>
> >> "!
> >>
> >>
> >> ------------------------------------------------------------------------
> >>
> >>
> >
> >
> >
> 
> 



More information about the Squeak-dev mailing list