[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
|