Thank you for your report.  I have transferred your report to Squeak's
Mantis Database and you can followup on the issue if desired by going to
http://bugs.impara.de/view.php?id=1545

In the future please report new issues on Squeak's Mantis Database at
http://bugs.impara.de/ .  Please see  
http://minnow.cc.gatech.edu/squeak/398  for more details.

thanks,
Larry Trutter

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.
>
>"!
>  
>
>------------------------------------------------------------------------
>
>
>  
>