[ENH] submorphsCleanup-efc

Andreas Raab andreas.raab at gmx.de
Sun Jul 24 21:47:41 UTC 2005


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