Hey Zulq - way to go with investigating the problem! :)


The point of declaring interests precisely is that it allows the system 
to make the right space/time trade offs. Declaring interest in 
everything is quite likely to create (memory) problems worse than those 
it solves. Let me give a little background.


Squeak, like other Smalltalks and some other modern IDEs, has a Shared 
Code Model, which is used for pretty much all editing and viewing. It is 
pretty minimal, and well optimized for straight forward tasks, like 
compact storage in memory, execution, editing, history viewing. Of 
course, people want to do and see more that what is on the surface, in 
the model - people want a real time lint tool, they want to see required 
(unimplemented, but self sent) methods and so forth - these are Model 
Extensions (MEs). And of course they want them to appear in real time, 
at low latency, so the MEs need to be cached. But caching every 
computation possible over all the code in the image is insane, so we 
require tools to declare Explicit Interests - tell me in advance what 
you might ask, then I can cache just that.


With regard to what Zulq did - I'm almost sure the tools are not 
actually interested in Local Sends, per se. But what is happening is 
that some of the dynamic categories use other MEs that use LocalSends 
for their calculations. You see, we have Layered Extensions, because 
sometimes its worth caching some intermediate results, not just end 
results. So what you want to do is make sure that the tools declare 
interest in what they actually ask about, and then make sure that each 
Model Extension declares interest in any temporary values it uses, such 
as Local Sends. In particular, a quick check shows that the dynamic 
protocols do not express interests in RequiredSelectors - fixing this 
would probably improve things significantly. In an old demo tool I wrote 
that did this, RequiredSelectors were shown in real time.


What I summarized above is a pattern language for smart, efficient code 
analysis tools, described in a pattern paper by Andrew Black and myself 
[1]. I think it has many potential applications in Squeak. I would not 
be surprised if it can be used to improve the responsiveness of the 
existing tools - if someone is interested.


[1]  http://web.cecs.pdx.edu/~black/publications/ModelExtensions.pdf


Daniel


Zulq Alam wrote:

> Hi Damien,
>
> I like the dynamic protocols but don't use them because of the 
> performance impact.
>
> I was curious and profiled it. It looks like the local send cache is 
> not being used as no interests are being declared.
>
> In the code below I declare interest in everything. I'm not sure about 
> the ramifications of this.
>
> When cached it is almost usable - perhaps with some tweaking this 
> excellent feature could be more widely used.
>
> Regards,
> Zulq.
>
> protocols := DynamicProtocols allAvailableProtocols.
> class := Object.
>
> " clear caches "
> protocols asArray collect: [:dp | dp invalidateCache].
> LocalSends current initialize.
>
> TimeProfileBrowser spyOn: [protocols
>         collect: [:dpClass | dpClass on: aClass]
>         thenSelect: [:dp | (dp getSelectorsFor: Object) notEmpty]].
> " 9.69 seconds "
>
> TimeProfileBrowser spyOn: [protocols
>         collect: [:dpClass | dpClass on: aClass]
>         thenSelect: [:dp | (dp getSelectorsFor: Object) notEmpty]].
> " 6.44 seconds - improvement from caches in dynamic protocols themselves"
>
> " declare interest in everything (maybe wrong) "
> LocalSends current
>     noteInterestOf: nil in: ProtoObject;
>     noteInterestOf: nil inAll: ProtoObject allSubclasses.
>
> " prime local send caches "
> TimeProfileBrowser spyOn: [protocols
>         collect: [:dpClass | dpClass on: aClass]
>         thenSelect: [:dp | (dp getSelectorsFor: Object) notEmpty]].
> "6.49 seconds "
>
> " local sends cached "
> TimeProfileBrowser spyOn: [protocols
>         collect: [:dpClass | dpClass on: aClass]
>         thenSelect: [:dp | (dp getSelectorsFor: Object) notEmpty]].
> "0.69 seconds "
>
>
> Damien Cassou wrote:
>> Hi,
>>
>> as the developer of both the Dynamic Protocols and the dev-images, I
>> have included the firsts into the latter some times ago. I found them
>> quite useful at that time. However, they slow down a lot the UI (which
>> is already very slow). So, my question is:
>>
>> Who wants me to continue including the dynamic protocols in the 
>> dev-images?
>>
>>
>> Is there anyone using them?
>>
>> Bye
>>
>
>