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@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.

"!

---

I often use copy in default access methods. The motivation is increaed robustness; it can be very risky to modify a collection. The 'submorphs copy' is presumably a way of implementing a read-only reference, ensuring that clients don't modify the collection in unsafe ways. One example is violating the submorph/owner invariant. Another is that the result of this expression is undefined: submorphs do: [:m | ........ ifTue: [m delete]])

Cheers -Trygve

At 21:07 25.07.2005, you wrote:

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@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@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.

"!

---