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