[DynamicProtocols] Loading from Store sucks...

> -----Original Message-----
> From: Reinout Heeck [mailto:[hidden email]]
> Sent: Wednesday, October 11, 2006 3:22 PM
> To: 'VWNC'
> Cc: [hidden email]; [hidden email]
> Subject: [DynamicProtocols] Loading from Store sucks...
>
> With DynamicProtocols loaded in my image it takes ages to
> load packages
> from Store.
>
>  From the MultitimeProfiler:
>
>
> 20715 samples, 21.81 average ms/sample, 3047 scavenges, 7 incGCs,
> 403.84s active, 32.89s semaphore waits,
> 451.83s real time, 15.1s profiling overhead
>
> ** Tree **
> 100.0 All processes
>   78.5 a Process named: Unlabeled Canvas at: 50
>   9.4 a Process named: FinalizationProcess at: 98
>   7.9 a Process named: ScavengeProcess at: 90
>   2.2 a Process named: LowSpaceProcess at: 91
>
>
> So 78.5% of our time is spent in the thread loading from Store.
> Looking deeper into that thread:
>
>
> 100.0 All processes
>   78.5 a Process named: Unlabeled Canvas at: 50
>    78.5 BlockClosure>>on:do:
>     78.5 [] in WindowManager>>newProcess
>      [...]
>       78.1 Store.AbstractTool>>loadPundle
>        [...]
>         75.8 ChangeSet class>>addSelector:class:attributes:
>          [...]
>          73.9
> Refactory.Browser.NavigatorPart>>dynamicProtocollsForClass:
>  
>
>
>
> Conclusion: about 94% of my time (73.9/78.5) is spent
> updating protocol
> views, the remaining 6% of the time is spent loading code.
>
> Loading code takes almost 20(!) times the time as originally...
>
>
> :-(
>
>
> R
> -
>
>
>

> What I also noticed was a very slow GUI update and heavy CPU usage when you have the protocol option on "Show all methods when no
> protocols are selected". IIRC they even appear twice, as regular and colored from the dynamic protocol. The more methods you have,
> the longer it takes, up to the point where I killed the image :(.
>
> IMHO, the dynamic protocols shouldn't be considered when the above option is set, but this probably can only be accomplished by a RB
> override. I wanted to look at it and if I could find a solution for it, but as usual, no spare time left for that - sigh.
> So I wished I could use them, but at the moment set them back for a while.
>
> Thomas
>
>  
>> -----Original Message-----
>> From: Reinout Heeck [mailto:[hidden email]]
>> Sent: Wednesday, October 11, 2006 3:22 PM
>> To: 'VWNC'
>> Cc: [hidden email]; [hidden email]
>> Subject: [DynamicProtocols] Loading from Store sucks...
>>
>> With DynamicProtocols loaded in my image it takes ages to
>> load packages
>> from Store.
>>
>>  From the MultitimeProfiler:
>>
>>
>> 20715 samples, 21.81 average ms/sample, 3047 scavenges, 7 incGCs,
>> 403.84s active, 32.89s semaphore waits,
>> 451.83s real time, 15.1s profiling overhead
>>
>> ** Tree **
>> 100.0 All processes
>>   78.5 a Process named: Unlabeled Canvas at: 50
>>   9.4 a Process named: FinalizationProcess at: 98
>>   7.9 a Process named: ScavengeProcess at: 90
>>   2.2 a Process named: LowSpaceProcess at: 91
>>
>>
>> So 78.5% of our time is spent in the thread loading from Store.
>> Looking deeper into that thread:
>>
>>
>> 100.0 All processes
>>   78.5 a Process named: Unlabeled Canvas at: 50
>>    78.5 BlockClosure>>on:do:
>>     78.5 [] in WindowManager>>newProcess
>>      [...]
>>       78.1 Store.AbstractTool>>loadPundle
>>        [...]
>>         75.8 ChangeSet class>>addSelector:class:attributes:
>>          [...]
>>          73.9
>> Refactory.Browser.NavigatorPart>>dynamicProtocollsForClass:
>>  
>>
>>
>>
>> Conclusion: about 94% of my time (73.9/78.5) is spent
>> updating protocol
>> views, the remaining 6% of the time is spent loading code.
>>
>> Loading code takes almost 20(!) times the time as originally...
>>
>>
>> :-(
>>
>>
>> R
>> -
>>
>>
>>
>>    
>
>
>  

> -----Original Message-----
> From: Karsten Kusche [mailto:[hidden email]]
> Sent: Wednesday, October 11, 2006 3:56 PM
> To: 'VWNC'
> Subject: Re: [DynamicProtocols] Loading from Store sucks...
>
> there's a settings page in the current release on public
> store where you
> can enable/disable certain protocolls.
> i'd also suggest that additional protocols should go into a
> new package,
> and not into the base package.
>
> Karsten
>
>
> Thomas Brodt wrote:
> > What I also noticed was a very slow GUI update and heavy
> CPU usage when you have the protocol option on "Show all
> methods when no
> > protocols are selected". IIRC they even appear twice, as
> regular and colored from the dynamic protocol. The more
> methods you have,
> > the longer it takes, up to the point where I killed the image :(.
> >
> > IMHO, the dynamic protocols shouldn't be considered when
> the above option is set, but this probably can only be
> accomplished by a RB
> > override. I wanted to look at it and if I could find a
> solution for it, but as usual, no spare time left for that - sigh.
> > So I wished I could use them, but at the moment set them
> back for a while.
> >
> > Thomas
> >
> >  
> >> -----Original Message-----
> >> From: Reinout Heeck [mailto:[hidden email]]
> >> Sent: Wednesday, October 11, 2006 3:22 PM
> >> To: 'VWNC'
> >> Cc: [hidden email]; [hidden email]
> >> Subject: [DynamicProtocols] Loading from Store sucks...
> >>
> >> With DynamicProtocols loaded in my image it takes ages to
> >> load packages
> >> from Store.
> >>
> >>  From the MultitimeProfiler:
> >>
> >>
> >> 20715 samples, 21.81 average ms/sample, 3047 scavenges, 7 incGCs,
> >> 403.84s active, 32.89s semaphore waits,
> >> 451.83s real time, 15.1s profiling overhead
> >>
> >> ** Tree **
> >> 100.0 All processes
> >>   78.5 a Process named: Unlabeled Canvas at: 50
> >>   9.4 a Process named: FinalizationProcess at: 98
> >>   7.9 a Process named: ScavengeProcess at: 90
> >>   2.2 a Process named: LowSpaceProcess at: 91
> >>
> >>
> >> So 78.5% of our time is spent in the thread loading from Store.
> >> Looking deeper into that thread:
> >>
> >>
> >> 100.0 All processes
> >>   78.5 a Process named: Unlabeled Canvas at: 50
> >>    78.5 BlockClosure>>on:do:
> >>     78.5 [] in WindowManager>>newProcess
> >>      [...]
> >>       78.1 Store.AbstractTool>>loadPundle
> >>        [...]
> >>         75.8 ChangeSet class>>addSelector:class:attributes:
> >>          [...]
> >>          73.9
> >> Refactory.Browser.NavigatorPart>>dynamicProtocollsForClass:
> >>  
> >>
> >>
> >>
> >> Conclusion: about 94% of my time (73.9/78.5) is spent
> >> updating protocol
> >> views, the remaining 6% of the time is spent loading code.
> >>
> >> Loading code takes almost 20(!) times the time as originally...
> >>
> >>
> >> :-(
> >>
> >>
> >> R
> >> -
> >>
> >>
> >>
> >>    
> >
> >
> >  
>
>

> Hi Karsten
>
> I'm not sure if I get your point (or you got mine).
> I do not want to switch some of the already defined dynamic protocols on or off. Nor do I want to add new dynamic protocol
> definitions to the package.
>
> I have the general RB option set to show all methods defined in the browsed class if not protocol is selected - that's convenient
> get an overview of all implemented methods or to do an alphabetic search by typing in the complete selector list. (See
> System->Settings->Browser, first checkbox labeled "Show all methods when no protocols are selected")
> In this view mode, the RB cumulates all methods from all protocols in the class. The problem is that it also cumulates methods
> listed in the dynamic protocols (as they are considered as protocols to contribute to the complete list), so the methods are
> considered twice or more often, once from the (real) protocol where they are organized, and additionally from the dynamic protocols
> where they fall into. (Maybe this even gets a loopback?)
> If I select a (dynamic or not) protocol, all is fine. Just if I deselect it, the list build algorithm sometimes bloes up when it
> computes the cumulated list from all (dynamic or not) protocols. And the default on browser open is to have no protocol selected....
>
> Thomas
>
>  
>> -----Original Message-----
>> From: Karsten Kusche [mailto:[hidden email]]
>> Sent: Wednesday, October 11, 2006 3:56 PM
>> To: 'VWNC'
>> Subject: Re: [DynamicProtocols] Loading from Store sucks...
>>
>> there's a settings page in the current release on public
>> store where you
>> can enable/disable certain protocolls.
>> i'd also suggest that additional protocols should go into a
>> new package,
>> and not into the base package.
>>
>> Karsten
>>
>>
>> Thomas Brodt wrote:
>>    
>>> What I also noticed was a very slow GUI update and heavy
>>>      
>> CPU usage when you have the protocol option on "Show all
>> methods when no
>>    
>>> protocols are selected". IIRC they even appear twice, as
>>>      
>> regular and colored from the dynamic protocol. The more
>> methods you have,
>>    
>>> the longer it takes, up to the point where I killed the image :(.
>>>
>>> IMHO, the dynamic protocols shouldn't be considered when
>>>      
>> the above option is set, but this probably can only be
>> accomplished by a RB
>>    
>>> override. I wanted to look at it and if I could find a
>>>      
>> solution for it, but as usual, no spare time left for that - sigh.
>>    
>>> So I wished I could use them, but at the moment set them
>>>      
>> back for a while.
>>    
>>> Thomas
>>>
>>>  
>>>      
>>>> -----Original Message-----
>>>> From: Reinout Heeck [mailto:[hidden email]]
>>>> Sent: Wednesday, October 11, 2006 3:22 PM
>>>> To: 'VWNC'
>>>> Cc: [hidden email]; [hidden email]
>>>> Subject: [DynamicProtocols] Loading from Store sucks...
>>>>
>>>> With DynamicProtocols loaded in my image it takes ages to
>>>> load packages
>>>> from Store.
>>>>
>>>>  From the MultitimeProfiler:
>>>>
>>>>
>>>> 20715 samples, 21.81 average ms/sample, 3047 scavenges, 7 incGCs,
>>>> 403.84s active, 32.89s semaphore waits,
>>>> 451.83s real time, 15.1s profiling overhead
>>>>
>>>> ** Tree **
>>>> 100.0 All processes
>>>>   78.5 a Process named: Unlabeled Canvas at: 50
>>>>   9.4 a Process named: FinalizationProcess at: 98
>>>>   7.9 a Process named: ScavengeProcess at: 90
>>>>   2.2 a Process named: LowSpaceProcess at: 91
>>>>
>>>>
>>>> So 78.5% of our time is spent in the thread loading from Store.
>>>> Looking deeper into that thread:
>>>>
>>>>
>>>> 100.0 All processes
>>>>   78.5 a Process named: Unlabeled Canvas at: 50
>>>>    78.5 BlockClosure>>on:do:
>>>>     78.5 [] in WindowManager>>newProcess
>>>>      [...]
>>>>       78.1 Store.AbstractTool>>loadPundle
>>>>        [...]
>>>>         75.8 ChangeSet class>>addSelector:class:attributes:
>>>>          [...]
>>>>          73.9
>>>> Refactory.Browser.NavigatorPart>>dynamicProtocollsForClass:
>>>>  
>>>>
>>>>
>>>>
>>>> Conclusion: about 94% of my time (73.9/78.5) is spent
>>>> updating protocol
>>>> views, the remaining 6% of the time is spent loading code.
>>>>
>>>> Loading code takes almost 20(!) times the time as originally...
>>>>
>>>>
>>>> :-(
>>>>
>>>>
>>>> R
>>>> -
>>>>
>>>>
>>>>
>>>>    
>>>>        
>>>  
>>>      
>>    
>
>
>  

> -----Original Message-----
> From: Karsten Kusche [mailto:[hidden email]]
> Sent: Wednesday, October 11, 2006 5:07 PM
> To: Thomas Brodt
> Cc: 'VWNC'
> Subject: Re: [DynamicProtocols] Loading from Store sucks...
>
> hi thomas,
>
> there is a method that dynamic protocols can implement which
> shows that
> protocol's methods also if no protocol is selected, but usually they
> should not be shown.
> to show methods also when the protocol is not selected is
> important for
> the 'required' protocol, cause these methods are simply not
> implemented
> yet, and thus are not shown.
> that method is called: #showIfNotSelected and returns false
> by default.
> so maybe it's just some of the protocols you have installed that show
> the methods when no protocol is selected, cause here
> everything works as
> expected.
>
> Karsten
>
>
> Thomas Brodt wrote:
> > Hi Karsten
> >
> > I'm not sure if I get your point (or you got mine).
> > I do not want to switch some of the already defined dynamic
> protocols on or off. Nor do I want to add new dynamic protocol
> > definitions to the package.
> >
> > I have the general RB option set to show all methods
> defined in the browsed class if not protocol is selected -
> that's convenient
> > get an overview of all implemented methods or to do an
> alphabetic search by typing in the complete selector list. (See
> > System->Settings->Browser, first checkbox labeled "Show all
> methods when no protocols are selected")
> > In this view mode, the RB cumulates all methods from all
> protocols in the class. The problem is that it also cumulates methods
> > listed in the dynamic protocols (as they are considered as
> protocols to contribute to the complete list), so the methods are
> > considered twice or more often, once from the (real)
> protocol where they are organized, and additionally from the
> dynamic protocols
> > where they fall into. (Maybe this even gets a loopback?)
> > If I select a (dynamic or not) protocol, all is fine. Just
> if I deselect it, the list build algorithm sometimes bloes up when it
> > computes the cumulated list from all (dynamic or not)
> protocols. And the default on browser open is to have no
> protocol selected....
> >
> > Thomas
> >
> >  
> >> -----Original Message-----
> >> From: Karsten Kusche [mailto:[hidden email]]
> >> Sent: Wednesday, October 11, 2006 3:56 PM
> >> To: 'VWNC'
> >> Subject: Re: [DynamicProtocols] Loading from Store sucks...
> >>
> >> there's a settings page in the current release on public
> >> store where you
> >> can enable/disable certain protocolls.
> >> i'd also suggest that additional protocols should go into a
> >> new package,
> >> and not into the base package.
> >>
> >> Karsten
> >>
> >>
> >> Thomas Brodt wrote:
> >>    
> >>> What I also noticed was a very slow GUI update and heavy
> >>>      
> >> CPU usage when you have the protocol option on "Show all
> >> methods when no
> >>    
> >>> protocols are selected". IIRC they even appear twice, as
> >>>      
> >> regular and colored from the dynamic protocol. The more
> >> methods you have,
> >>    
> >>> the longer it takes, up to the point where I killed the image :(.
> >>>
> >>> IMHO, the dynamic protocols shouldn't be considered when
> >>>      
> >> the above option is set, but this probably can only be
> >> accomplished by a RB
> >>    
> >>> override. I wanted to look at it and if I could find a
> >>>      
> >> solution for it, but as usual, no spare time left for that - sigh.
> >>    
> >>> So I wished I could use them, but at the moment set them
> >>>      
> >> back for a while.
> >>    
> >>> Thomas
> >>>
> >>>  
> >>>      
> >>>> -----Original Message-----
> >>>> From: Reinout Heeck [mailto:[hidden email]]
> >>>> Sent: Wednesday, October 11, 2006 3:22 PM
> >>>> To: 'VWNC'
> >>>> Cc: [hidden email]; [hidden email]
> >>>> Subject: [DynamicProtocols] Loading from Store sucks...
> >>>>
> >>>> With DynamicProtocols loaded in my image it takes ages to
> >>>> load packages
> >>>> from Store.
> >>>>
> >>>>  From the MultitimeProfiler:
> >>>>
> >>>>
> >>>> 20715 samples, 21.81 average ms/sample, 3047 scavenges, 7 incGCs,
> >>>> 403.84s active, 32.89s semaphore waits,
> >>>> 451.83s real time, 15.1s profiling overhead
> >>>>
> >>>> ** Tree **
> >>>> 100.0 All processes
> >>>>   78.5 a Process named: Unlabeled Canvas at: 50
> >>>>   9.4 a Process named: FinalizationProcess at: 98
> >>>>   7.9 a Process named: ScavengeProcess at: 90
> >>>>   2.2 a Process named: LowSpaceProcess at: 91
> >>>>
> >>>>
> >>>> So 78.5% of our time is spent in the thread loading from Store.
> >>>> Looking deeper into that thread:
> >>>>
> >>>>
> >>>> 100.0 All processes
> >>>>   78.5 a Process named: Unlabeled Canvas at: 50
> >>>>    78.5 BlockClosure>>on:do:
> >>>>     78.5 [] in WindowManager>>newProcess
> >>>>      [...]
> >>>>       78.1 Store.AbstractTool>>loadPundle
> >>>>        [...]
> >>>>         75.8 ChangeSet class>>addSelector:class:attributes:
> >>>>          [...]
> >>>>          73.9
> >>>> Refactory.Browser.NavigatorPart>>dynamicProtocollsForClass:
> >>>>  
> >>>>
> >>>>
> >>>>
> >>>> Conclusion: about 94% of my time (73.9/78.5) is spent
> >>>> updating protocol
> >>>> views, the remaining 6% of the time is spent loading code.
> >>>>
> >>>> Loading code takes almost 20(!) times the time as originally...
> >>>>
> >>>>
> >>>> :-(
> >>>>
> >>>>
> >>>> R
> >>>> -
> >>>>
> >>>>
> >>>>
> >>>>    
> >>>>        
> >>>  
> >>>      
> >>    
> >
> >
> >  
>

>Georg Heeg wrote:
>>Reinhout,
>>
>>this is a more general problem. Thus we developed a new thing called RB
>>Suppress Useless Updates (AR 48877). It is currently in review.
>>
>>George
>>  
>I loaded the parcel you posted here on 3/18/2006 (version = 1.2) but that does not seem to fix the problem.
>I still spend > 90% of my time in ChangeSet class>>addSelector:class:attributes:
>
>
>Do you have a newer version available or is this an unfixed problem?