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

Igor Stasenko siguctua at gmail.com
Fri Feb 11 22:59:11 UTC 2011


On 11 February 2011 23:01, Levente Uzonyi <leves at elte.hu> wrote:
> 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).

Same mistake again.
Fix the error that some morphs are not visible through world (probably
due to belonging to other PasteUpMorph instance).
So you still don't have to use VM heap walk to iterate over them.
Moreover, i pretty sure that you can skip those morphs, which are not
taking part in UI interaction (what undo history could have a morph,
which
never seen its way to world?).

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

And you don't need all morphs.

>
> Levente
>


-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list