Iterating over all Morphs (was: Re: [squeak-dev] Object>>is:)

Levente Uzonyi leves at elte.hu
Fri Feb 11 22:01:56 UTC 2011


On Fri, 11 Feb 2011, Igor Stasenko wrote:

> On 11 February 2011 17:02, Levente Uzonyi <leves at elte.hu> wrote:
>> On Fri, 11 Feb 2011, Igor Stasenko wrote:
>>
>>> On 11 February 2011 15:57, Levente Uzonyi <leves at elte.hu> wrote:
>>>>
>>>> On Fri, 11 Feb 2011, Igor Stasenko wrote:
>>>>
>>>>> Since this method is hardly useful from any other code but morphic,
>>>>> then what it does in SmalltalkImage?
>>>>
>>>> That's a good question, but unrelated to this thread.
>>>>
>>>>> It should belong to UI universe.. and UI uninverse should know how to
>>>>> tell all morphs to do that cleanup.. and then you don't need anything
>>>>> related to it in Object protocol.
>>>>> It makes no sense asking every object in system in a way like that.
>>>>
>>>> It's a lot faster asking all objects, than asking only the Morphs.
>>>>
>>>
>>> Morphs are just a subset of all objects.. So, please tell me how
>>> sending a message to all objects could be faster than sending message
>>> to all morphs? :)
>>
>> I guess you didn't think about the problem. How do you select all morphs?
>>
> you can do something like:
>  World blahblah...
> no?
> I am sure, if you look deeply there is a way to iterate over all submorphs tree.

You can, but that doesn't find all the Morphs:

c1 := c2 := 0.
World allMorphsDo: [ :x | c1 := c1 + 1 ].
Morph allSubInstancesDo: [ :each | c2 := c2 + 1 ].
{ c1. c2 }. #(1054 3600).

>
> And don't say that it will be slower than iterating over all objects
> in object memory.

No, it's faster, but it doesn't find all Morphs.

>
> But even if you do, then why not iterating over morphs , so you don't
> have to use #isMorph
>
> Morph allSubInstancesDo: ...

The slow implementation which I replaced with #allObjectsDo: did the same 
as Morph allSubInstancesDo: [ ... ].

>
>>>
>>>>>
>>>>> So, all you need is to think a bit more broadly in a sense, how to
>>>>> improve system and remove crappy patterns from use,
>>>>> but not blindly replace one pattern by another , which replacing one
>>>>> flood with another.
>>>>
>>>> If you can show a pattern for this which has comparable performance with
>>>> the
>>>> current implementation, then I'm all ears.
>>>>
>>>
>>> Since when performance became the only criteria for reasoning about
>>> implementation quality?
>>
>> Who said it's the only criteria (besides you)?
>> Btw, the previous implementation of this method was slow. It annoyed me so
>> much that I changed it to the current implememtation which uses
>> allObjectsDo: and is 22x faster for a Trunk image.
>>
>
> Why then to not change the implementation?

I changed the implementation. :)

> Why you fighting with imlementation being slow, without getting
> interested why it implemented in such manner,
> which is the main reason why its so slow.

It's not slow anymore, and I still doubt you could make it faster without 
changing the VM or registering all morphs to some collection. But I'm 
still all ears to a better implementation.

>
> Did you asked yourself, why cleaning up the undo commands in morphs is
> responsibility of SmalltalkImage class ??

As I wrote before, this is an important question, but irrelevant in 
this thread.

> Why it is not responsibility of morphic world/project.

Because they don't contain all morphs?


Levente

>
> So, yeah.. keep fighting with consequences instead of dealing with cause.
>
>>
>> Levente
>
>
>
> -- 
> Best regards,
> Igor Stasenko AKA sig.
>
>



More information about the Squeak-dev mailing list