[squeak-dev] Object>>is:

Ricardo Moran richi.moran at gmail.com
Fri Feb 11 19:23:06 UTC 2011


On Fri, Feb 11, 2011 at 3:29 PM, Igor Stasenko <siguctua at gmail.com> wrote:>
(snip)

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

I think you mean

World>>#allMorphsDo:

and in my experience it is *much* faster than iterating over all objects.

Cheers
Richo


>
> And don't say that it will be slower than iterating over all objects
> in object memory.
>
> But even if you do, then why not iterating over morphs , so you don't
> have to use #isMorph
>
> 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?
> 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.
>
> Did you asked yourself, why cleaning up the undo commands in morphs is
> responsibility of SmalltalkImage class ??
> Why it is not responsibility of morphic world/project.
>
> So, yeah.. keep fighting with consequences instead of dealing with cause.
>
> >
> > Levente
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110211/d3393753/attachment.htm


More information about the Squeak-dev mailing list