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.pdfDaniel
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
>>
>
>
Locked
smime.p7s (3K)