Damien Cassou wrote:
[snip]
> I think RequiredSelectors does its job well (the algorithm is complex
> and is the subject of an scientific article). We probably have to use
> it in some way. Maybe we just have to set up an interest on this
> class, I don't know.
>   
This is exactly right. Nathanael has written very efficient code for 
calculating the required methods of all subclasses of a class at once, 
but it is not efficient enough to always calculate the whole image. 
Running it on a particular class as needed is very inefficient. By 
registering interest in every class in every category being displayed at 
the moment, we allow the Model Extension mechanism to calculate exactly 
what is needed by running Nathanael's code only on what needs to be 
updated, in as large a batch as possible. This allows all queries to be 
answered from one unified cache for all active browsers and tools, that 
is updated as efficiently as possible, and only when necessary (relevant 
code is changed).

Daniel

>
> Good luck
>
> On Feb 7, 2008 12:06 AM, Zulq Alam <me at zulq.net> wrote:
>   
>> Apologies for the long post. There have been so many lately. I wanted to
>> share my progress and thoughts about dynamic protocol performance.
>>
>> There are four really troublesome dynamic protocols:
>>
>>    DPLong          reads all sources
>>    DPUncommented   reads all sources
>>    DPSupplied      lengthy analysis, no caching
>>    DPRequired      lengthy analysis, no caching
>>
>> When you browse to a class or a browser refreshes, each dynamic protocol
>> is (re)calculated to determine whether it should be listed. It is then
>> recalculated when selected. If the protocol is cacheable, the cache will
>> be used when populated. Refreshes can be triggered by browsing, class
>> changes or do-its and print-its (many of these unrelated).
>>
>> I've uploaded a package to SqueakSource which should help
>> (DynamicProtocols-za.69). On the basis that it is better to list an
>> empty protocol I allow protocols to define a pain threshold. If the
>> target class has more selectors than this pain threshold, the protocol
>> is always displayed and only calculated when accessed.
>>
>> To help determine whether a protocol has been calculated, protocol names
>> now include the number of methods they contain, e.g. "-- long (?) --" or
>> "-- override (3) --". A "?" means the number of selectors is above the
>> pain threshold and the protocol will be calculated on access.
>>
>> I've also had a stab at the required protocol (the worst offender):
>>
>> | selectors  |
>> selectors := Set new.
>> aClass allSuperclasses reverseDo:
>>    [:eachSuperclass |
>>    eachSuperclass selectorsAndMethodsDo:
>>      [:eachSelector :eachMethod |
>>      selectors remove: eachSelector ifAbsent: [].
>>      eachMethod isRequired
>>        ifTrue: [selectors add: eachSelector]]].
>> selectors removeAllFoundIn: aClass selectors.
>> ^ selectors
>>
>> This is faster than using Behaviour>>#requiredSelectors but also gives
>> completely different results! I have either misunderstood what
>> "required" means or something isn't right with one or the other.
>>
>> For example, "AColorSelectorMorph requiredSelectors" answers 16
>> selectors that are not required, many are not even from the same hierarchy.
>>
>> Anyway, the pain thresholds probably needs some adjustment but it all
>> seems useable in my image. I'd be interested to hear how it works for
>> others and any comments on changes.
>>
>> Thanks,
>> Zulq.
>>
>>
>>
>>     
>
>
>
>   
> ------------------------------------------------------------------------
>
>
>