Out UI's Slowed down 10x or more between VW7.7.1 and VW7.9.1 ...

> What a coincidence!
>
> I started today working on upgrading our application to vw7.9.1 and also noticed this change in #componentAt:
>
> I'm considering making a new method with the old behavior and change our code to use this new method. I think the current implementation in VW7.9.1 is quite unreliable.
>
> @Cincom: What was the reason for introducing this "search for a widget anywhere on the window"?
>
> It means, for instance, that if you're in a subcanvas and you write code like this:
>
> (self builder componentAt: #myComponent) ifNotNil: [:c | ...]
>
> that you're no longer sure that the component that's returned really is part of the subcanvas since the method looks for the component in the entire Window's component tree:
>
> componentAt: aKey
> "Retrieve the wrapperInterface or other object that goes by the same id, of the indicated component."
>
> namedComponents at: aKey
> ifPresent: [:each | each ifNotNil: [:visual | ^visual wrapperInterface]].
> (self searchCurrentCompositeViewTreeForID: aKey) ifNotNil: [:view | ^view].
> (self searchTopWindowViewTreeForID: aKey) ifNotNil: [:view | ^view].
> ^nil
>
> This sounds like looking for trouble...
>
> What would go wrong if I would revert the method to the vw7.7.0 behavior where only the dictionary of #namedComponents was used? I can replace our senders with a new method, but we've got quite a few senders and the current implementation of #componentAt: looks unreliable to me. It will probably cause us problems if people incorrectly start using it...
>
> Mark
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Dennis Smith
> Sent: donderdag 7 februari 2013 14:10
> To: [hidden email]
> Subject: [vwnc] Out UI's Slowed down 10x or more between VW7.7.1 and VW7.9.1 ...
>
> The cuplrit is  UIbuilder>>componentAt:   which now seems to search most
> of the universe trying to find some component somewhere.
>
> It used to just look in that builder's dictionary, it now searches other
> builders??
>
> Anyone seen this as a problem?  Anyone know why???
>

> What a coincidence!
>
> I started today working on upgrading our application to vw7.9.1 and also noticed this change in #componentAt:
>
> I'm considering making a new method with the old behavior and change our code to use this new method. I think the current implementation in VW7.9.1 is quite unreliable.
>
> @Cincom: What was the reason for introducing this "search for a widget anywhere on the window"?
>
> It means, for instance, that if you're in a subcanvas and you write code like this:
>
> (self builder componentAt: #myComponent) ifNotNil: [:c | ...]
>
> that you're no longer sure that the component that's returned really is part of the subcanvas since the method looks for the component in the entire Window's component tree:
>
> componentAt: aKey
> "Retrieve the wrapperInterface or other object that goes by the same id, of the indicated component."
>
> namedComponents at: aKey
> ifPresent: [:each | each ifNotNil: [:visual | ^visual wrapperInterface]].
> (self searchCurrentCompositeViewTreeForID: aKey) ifNotNil: [:view | ^view].
> (self searchTopWindowViewTreeForID: aKey) ifNotNil: [:view | ^view].
> ^nil
>
> This sounds like looking for trouble...
>
> What would go wrong if I would revert the method to the vw7.7.0 behavior where only the dictionary of #namedComponents was used? I can replace our senders with a new method, but we've got quite a few senders and the current implementation of #componentAt: looks unreliable to me. It will probably cause us problems if people incorrectly start using it...
>
> Mark
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Dennis Smith
> Sent: donderdag 7 februari 2013 14:10
> To: [hidden email]
> Subject: [vwnc] Out UI's Slowed down 10x or more between VW7.7.1 and VW7.9.1 ...
>
> The cuplrit is  UIbuilder>>componentAt:   which now seems to search most
> of the universe trying to find some component somewhere.
>
> It used to just look in that builder's dictionary, it now searches
> other builders??
>
> Anyone seen this as a problem?  Anyone know why???
>

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Mark Plas
> Sent: Thursday, February 7, 2013 4:15 PM
> To: Dennis Smith; vwnc >> "[hidden email]"
> Subject: Re: [vwnc] Out UI's Slowed down 10x or more between VW7.7.1
> and VW7.9.1 ...
>
> Good idea about the subclass!
>
> we already have one. I will restore the basic behavior on that one.
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On
> Behalf Of Dennis Smith
> Sent: donderdag 7 februari 2013 15:03
> To: vwnc >> "[hidden email]"
> Subject: Re: [vwnc] Out UI's Slowed down 10x or more between VW7.7.1
> and VW7.9.1 ...
>
> Just for fun I changed the method back to what it used to be and ran
> browsers and debuggers etc -- all fine.
>
> For now my solution is a subclass which has the old method and each of
> my applications (all use a common superclass) do a
>      aBuilder changeClasssTo: NewBuilderClass
>
> so that protects VW apps, but lets mine be faster.
>
> I too would like to hear what cincom says about it??
>
>
>
> On 2013-02-07 8:54 AM, Mark Plas wrote:
> > What a coincidence!
> >
> > I started today working on upgrading our application to vw7.9.1 and
> also noticed this change in #componentAt:
> >
> > I'm considering making a new method with the old behavior and change
> our code to use this new method. I think the current implementation in
> VW7.9.1 is quite unreliable.
> >
> > @Cincom: What was the reason for introducing this "search for a
> widget anywhere on the window"?
> >
> > It means, for instance, that if you're in a subcanvas and you write
> code like this:
> >
> > (self builder componentAt: #myComponent) ifNotNil: [:c
> | ...]
> >
> > that you're no longer sure that the component that's returned really
> is part of the subcanvas since the method looks for the component in
> the entire Window's component tree:
> >
> > componentAt: aKey
> > "Retrieve the wrapperInterface or other object that goes by
> the same id, of the indicated component."
> >
> > namedComponents at: aKey
> > ifPresent: [:each | each ifNotNil: [:visual |
> ^visual wrapperInterface]].
> > (self searchCurrentCompositeViewTreeForID: aKey) ifNotNil:
> [:view | ^view].
> > (self searchTopWindowViewTreeForID: aKey) ifNotNil: [:view |
> ^view].
> > ^nil
> >
> > This sounds like looking for trouble...
> >
> > What would go wrong if I would revert the method to the vw7.7.0
> behavior where only the dictionary of #namedComponents was used? I can
> replace our senders with a new method, but we've got quite a few
> senders and the current implementation of #componentAt: looks
> unreliable to me. It will probably cause us problems if people
> incorrectly start using it...
> >
> > Mark
> >
> >
> > -----Original Message-----
> > From: [hidden email] [mailto:[hidden email]] On
> > Behalf Of Dennis Smith
> > Sent: donderdag 7 februari 2013 14:10
> > To: [hidden email]
> > Subject: [vwnc] Out UI's Slowed down 10x or more between VW7.7.1 and
> VW7.9.1 ...
> >
> > The cuplrit is  UIbuilder>>componentAt:   which now seems to search
> most
> > of the universe trying to find some component somewhere.
> >
> > It used to just look in that builder's dictionary, it now searches
> > other builders??
> >
> > Anyone seen this as a problem?  Anyone know why???
> >
>
> --
> Dennis Smith                                  +1 416.798.7948
> Cherniak Software Development Corporation   Fax: +1 416.798.0948
> 509-2001 Sheppard Avenue East        [hidden email]
> Toronto, ON M2J 4Z8              sip:[hidden email]
> Canada                     http://www.CherniakSoftware.com
> Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

> I imagine this is related to what Travis Griggs suggested on vw-dev:
> http://www.parcplace.net/list/vw-dev/1110/msg00012.html
> (only visible if you're signed up to vw-dev)
> http://objology.blogspot.com/2011/10/sounding-out-view-tree.html
>
> I commented then that I didn't like the automatic deep search:
>> Also, I'm not sure about walking the tree as far as possible in one
>> direction or the other. It's not needed very often, and it may end up
>> finding something surprising deep in some subcanvas. Most of my
>> navigation is simply down one level, to a widget that I've explicitly
>> named, so the explicit "self widgetAt: #tree" is better than the more
>> eager-to-help "self ? #tree", which like a puppy may run off and fetch
>> something I didn't want, which will then get mangled.
> ...
>> If I had deep subcanvases, I wouldn't want a method at the top level
>> to manipulate UI components deep inside. That would seem to break
>> the modularization, which I'd see as one of the benefits of
>> subcanvases. I'd rather have each subcanvas have its own
>> ApplicationModel and take care of its own bit of the UI.
> Steve
>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On
>> Behalf Of Mark Plas
>> Sent: Thursday, February 7, 2013 4:15 PM
>> To: Dennis Smith; vwnc >> "[hidden email]"
>> Subject: Re: [vwnc] Out UI's Slowed down 10x or more between VW7.7.1
>> and VW7.9.1 ...
>>
>> Good idea about the subclass!
>>
>> we already have one. I will restore the basic behavior on that one.
>>
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]] On
>> Behalf Of Dennis Smith
>> Sent: donderdag 7 februari 2013 15:03
>> To: vwnc >> "[hidden email]"
>> Subject: Re: [vwnc] Out UI's Slowed down 10x or more between VW7.7.1
>> and VW7.9.1 ...
>>
>> Just for fun I changed the method back to what it used to be and ran
>> browsers and debuggers etc -- all fine.
>>
>> For now my solution is a subclass which has the old method and each of
>> my applications (all use a common superclass) do a
>>       aBuilder changeClasssTo: NewBuilderClass
>>
>> so that protects VW apps, but lets mine be faster.
>>
>> I too would like to hear what cincom says about it??
>>
>>
>>
>> On 2013-02-07 8:54 AM, Mark Plas wrote:
>>> What a coincidence!
>>>
>>> I started today working on upgrading our application to vw7.9.1 and
>> also noticed this change in #componentAt:
>>> I'm considering making a new method with the old behavior and change
>> our code to use this new method. I think the current implementation in
>> VW7.9.1 is quite unreliable.
>>> @Cincom: What was the reason for introducing this "search for a
>> widget anywhere on the window"?
>>> It means, for instance, that if you're in a subcanvas and you write
>> code like this:
>>> (self builder componentAt: #myComponent) ifNotNil: [:c
>> | ...]
>>> that you're no longer sure that the component that's returned really
>> is part of the subcanvas since the method looks for the component in
>> the entire Window's component tree:
>>> componentAt: aKey
>>> "Retrieve the wrapperInterface or other object that goes by
>> the same id, of the indicated component."
>>> namedComponents at: aKey
>>> ifPresent: [:each | each ifNotNil: [:visual |
>> ^visual wrapperInterface]].
>>> (self searchCurrentCompositeViewTreeForID: aKey) ifNotNil:
>> [:view | ^view].
>>> (self searchTopWindowViewTreeForID: aKey) ifNotNil: [:view |
>> ^view].
>>> ^nil
>>>
>>> This sounds like looking for trouble...
>>>
>>> What would go wrong if I would revert the method to the vw7.7.0
>> behavior where only the dictionary of #namedComponents was used? I can
>> replace our senders with a new method, but we've got quite a few
>> senders and the current implementation of #componentAt: looks
>> unreliable to me. It will probably cause us problems if people
>> incorrectly start using it...
>>> Mark
>>>
>>>
>>> -----Original Message-----
>>> From: [hidden email] [mailto:[hidden email]] On
>>> Behalf Of Dennis Smith
>>> Sent: donderdag 7 februari 2013 14:10
>>> To: [hidden email]
>>> Subject: [vwnc] Out UI's Slowed down 10x or more between VW7.7.1 and
>> VW7.9.1 ...
>>> The cuplrit is  UIbuilder>>componentAt:   which now seems to search
>> most
>>> of the universe trying to find some component somewhere.
>>>
>>> It used to just look in that builder's dictionary, it now searches
>>> other builders??
>>>
>>> Anyone seen this as a problem?  Anyone know why???
>>>
>> --
>> Dennis Smith                                  +1 416.798.7948
>> Cherniak Software Development Corporation   Fax: +1 416.798.0948
>> 509-2001 Sheppard Avenue East        [hidden email]
>> Toronto, ON M2J 4Z8              sip:[hidden email]
>> Canada                     http://www.CherniakSoftware.com
>> Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP
>>
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc