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

Levente Uzonyi leves at elte.hu
Fri Feb 11 23:14:38 UTC 2011


On Fri, 11 Feb 2011, Igor Stasenko wrote:

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

I doubt that's an error.

> So you still don't have to use VM heap walk to iterate over them.

If you use #allInstancesDo:, then I'm pretty sure you'll go though the 
whole heap. I guess #someInstance (primitive 77) is implemented as walking 
throught the heap from the start and looking for the first instance of the 
given class (receiver). And #nextInstance (primitive 78) just keeps 
searching from the current object (receiver). But I'm too lazy to check 
it.

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

I don't know, and to be honest, I don't want to know. :) Btw I found 
another way to kill the undo commands, which uses a single 
#allInstancesDo: send and doesn't send #isMorph. ;)


Levente

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