Dynamic Protocols in the Dev-images

> 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
> >
>
>
>

> "Daniel Vainsencher" <[hidden email]> wrote
>
>  
>> [1]  http://web.cecs.pdx.edu/~black/publications/ModelExtensions.pdf
>>    
>
> Very nice paper, thank you.
>
> Sophie
>
>
>
>
>  

>> [1]  http://web.cecs.pdx.edu/~black/publications/ModelExtensions.pdf
>>    
>
> On page 22 of this paper, you mentioned that the notification
> mechanism should tell you the previous values of classes and
> methods for the purpose of cache invalidation.
>
> Goran and I made just these changes to SystemChangeNotifier in
> Squeak as part of our DeltaStreams project; now, when classes,
> methods, and class comments are changed, a notification with both
> the old and new version is sent. It is completely
> backward-compatible with the old SystemChangeNotifier protocol,
> as far as we can tell:
>
> http://map.squeak.org/packagebyname/deltastreamfixes
>
> In the future (a month or two), I'm going to augment the
> notifier again to support grouping of related changes, such as
> all changes involved in loading a package, filing-in a
> changeset, or loading a bug-fix, so that the enhanced logging
> features of DeltaStreams can show system changes at more the
> level the user made them; loading a package was a single-action
> to them; the log should show it as a single action.
>
>  

>>> Keep DynamicProtocols preinstalled in dev-image and set preference
>>> option to false by default (dynamicProtocolActivation).
>>
>> This was my idea too.
>> --
>> Damien Cassou
>
> I'd think the things pre-installed are the ones that mostly everyone  
> uses,
> like Shout and OmniBrowser. You long ago moved optional packages to  
> the
> Universe, why would DynamicProtocols be any different?
>
> Ramon Leon
> http://onsmalltalk.com
>
>
>

>>> Dumb question:  What *are* they used for in the dev image
>>> when turned on?
>>
>> Real answer, from memory, dynamically computed method protocols,  
>> just look
>> at the list of categories in your preferences under dynamic  
>> protocols.
>> Interesting idea, but Squeak's UI is slow enough as it is, it  
>> doesn't have
>> extra cycles to spare.
> Which is, if you think about it, a quite ridiculous state of  
> affairs. Ten years ago with machines that struggled to achieve  
> tinyBenchmark figures of 3 million bc/sec we were able to use the UI  
> tolerably. My current machine manages 544 million bc/sec  - 180  
> times as fast - and yet the UI is if anything slower and less  
> usable. And this is in a plain 3.9 image without the cpu-sucking  
> dynamic protocols!
>
> Insane.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> "Bother," said Pooh, reading his bank statement from Barings.
>
>
>
>

>> [1]  http://web.cecs.pdx.edu/~black/publications/ModelExtensions.pdf
>
> On page 22 of this paper, you mentioned that the notification
> mechanism should tell you the previous values of classes and
> methods for the purpose of cache invalidation.
>
> Goran and I made just these changes to SystemChangeNotifier in
> Squeak as part of our DeltaStreams project; now, when classes,
> methods, and class comments are changed, a notification with both
> the old and new version is sent. It is completely
> backward-compatible with the old SystemChangeNotifier protocol,
> as far as we can tell:
>
> http://map.squeak.org/packagebyname/deltastreamfixes
>
> In the future (a month or two), I'm going to augment the
> notifier again to support grouping of related changes, such as
> all changes involved in loading a package, filing-in a
> changeset, or loading a bug-fix, so that the enhanced logging
> features of DeltaStreams can show system changes at more the
> level the user made them; loading a package was a single-action
> to them; the log should show it as a single action.
>
> --
> Matthew Fulmer -- http://mtfulmer.wordpress.com/
> Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
>
>

>
> stephane ducasse wrote:
>
>> I also got the impression that at each doit I did the protocols got  
>> recomputed....arghh
>
> You are correct. Each instance of OBCodeBrowser is registered to be  
> notified of all system changes. Notification triggers regeneration  
> of dynamic protocols.
>
> A "do it" or "print it" is evaluated using  
> Compiler>>#evaluate:in:to:notifying:ifFail:logged: which triggers  
> this notification.
>
> Confusingly, when you "debug it", this notification isn't sent. The  
> code is compiled and executed but no notification is sent.
>
> But, if you debug something that does change the system like:  
> "Object compile: 'dude ^ ''sweet'''" then a notification is triggered.
>
> I conclude that either "debug it" isn't correctly notifying or "do  
> it"/"print it" are sending out unnecessary notifications.
>
> With regard to dynamic protocols, none of this should matter if it  
> were fast enough although it would help to reduce the number of  
> times they are regenerated.
>
> Regards,
> Zulq.
>
>
>