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
|