Dynamic protocol performance

Juan José Evangelista juanjoe at gmail.com
Thu Feb 7 02:21:51 UTC 2008


Hello, first of all, sorry for my english. I'll try to make me  
understand.

I like the idea behind dynamic protocols, but in fact, I have it  
deactivated in my working image.

The first thing that is annoying to me is the progress bar. I think  
that in this particular case it makes the feel of a more slow  
function. I make a clik on a class and i see a little window that  
appear and dissapear. perhaps is better to no show anything.

The other think that I'm thinking, I don't know if it is possible with  
the OB design, but can you make the calculations in an asynchronic way?
So if I click on a class, I see the normal protocols without stopping  
my work and in less than a second a few extra protocols appear. I  
don't know, it's an idea.

Regards
-------------------------------------------
La vida es como un partido de ajedrez contra uno mismo. Siempre ganás,
siempre perdés.

On 06/02/2008, at 21:06, Zulq Alam 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.
>
>




More information about the Squeak-dev mailing list