Fwd: [squeak-dev] Re: Usability and look-and-feel (was Re: The future ofSqueak & Pharo (was Re: [ANN] Pharo MIT licenseclean))

> On 09.07.2009 23:03, Lukas Renggli wrote:
>>
>>> OUCH!!!!  That's quite an example; just for giggles, I started up  
>>> a 3.9 polymorph image and retraced my steps (via message names,  
>>> same as in Pharo) and  had a prompt reply.  After doing that, I  
>>> found that Pharo (win32) had indeed completed the task.
>>>
>>
>> Again, this has nothing to do with Pharo, OmniBrowser or Polymorph.
>>
>> This is PackageInfo that is so slow when trying to find out the  
>> owning
>> package of each of the 6334 methods. If the display of the package  
>> for
>> every method is removed the sender browser opens almost instantly.
>>
>> Lukas
>>
>>
> Hmmm, really? I do have a fast machine, and it ran in 1,7 seconds  
> for me, but when I run TimeProfileBrowser on the block (first time,  
> later runs alot of stuff is already cached and thus won't show up as  
> prominently if you do TimeProfile on opening a batch of windows ), I  
> get the following percentages:
> - 32% building the dynamic "all" category
>     - 19% reading all subclass selectors (these are then cached).
>     - 13% reading the timestamp of the compiledMethods /(these are  
> then cached) from sources to see if they're recent
> - 20% finding extension classes, amongst other things PackageInfo  
> here spends half that time doing an includes: check with an  
> OrderedCollection with 174 elements...
> -41% building the OB UI.
> -7% GC'ing
>
> A good increase in response time could probably be seen by, as you  
> said, not selecting all category by default, instead promising of  
> it's calculation (In VisualWorks anyways, for those who don't know,  
> it's the same as a fork which returns a value, but blocks if the  
> value it attempted to be used before it's finished calculated).
>
> 2 small Performance "bugs" I encountered while checking the methods:
> OBPackagesOrClassNode>>addUnpackagedCategories: categories to: pkgs  
> does:
>     SystemOrganization categories asSet difference: categories
> Looking at what the includes check in difference: is done against,  
> it's clear the code should be:
>     SystemOrganization categories difference: categories asSet.
> Difference: 500 repetitions in the debugger I had open at the time:  
> 10866 ms vs 581 ms. (20 times faster)
>
> PackageInfo >> externalClasses
> reads:
>     myClasses := self classesAndMetaClasses.
> then does an includes: check, could add an asSet on end there:
>     myClasses := self classesAndMetaClasses asSet.
> Difference: 500 repetitions in the debugger I had open at the time:  
> 105444ms vs  11447 ms (9 times faster)
>
> With these 2 changes, the 20% in finding extension classes was  
> reduced to 11%.
>
> Cheers,
> Henry
>
>
>
> <UseSetForIncludes.
> 1.cs>_______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Lukas Renggli wrote:
>>> OUCH!!!!  That's quite an example; just for giggles, I started up a
>>> 3.9 polymorph image and retraced my steps (via message names, same
>>> as in Pharo) and  had a prompt reply.  After doing that, I found
>>> that Pharo (win32) had indeed completed the task.
>>
>> Again, this has nothing to do with Pharo, OmniBrowser or Polymorph.
>>
>> This is PackageInfo that is so slow when trying to find out the
>> owning package of each of the 6334 methods. If the display of the
>> package for every method is removed the sender browser opens almost
>> instantly.
>
> Then we should remove or at least temporarily disable it. The user
> doesn't care why something is slow.
>
> michael
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Stef,
>
> One of my greatest concerns about/for the Squeak community is an  
> overall tone of "*YOU* can't do that because *I* think its's ugly" -  
> or in this case, too slow.  So, far be it from me to tell you that  
> you cannot have even a super slow browser that does something you  
> need.  That's all the more true when you are doing such great things  
> for Smalltalk and Pharo in particular.  I am certainly not  
> suggesting that we remove the browser that helps you make things  
> better.
>
> However, I suggest that we consider carefully what we choose as the  
> default tools, or at least give options to those who are finding the  
> current defaults to be slow.  Even if we continue with the OB as the  
> default, we could at least have a script somewhere with a comment  
> along the lines of "for a faster (at the expense of features) IDE,  
> evaluate the following:".

> On 09.07.2009 23:03, Lukas Renggli wrote:
>>
>>> OUCH!!!!  That's quite an example; just for giggles, I started up  
>>> a 3.9 polymorph image and retraced my steps (via message names,  
>>> same as in Pharo) and  had a prompt reply.  After doing that, I  
>>> found that Pharo (win32) had indeed completed the task.
>>>
>>
>> Again, this has nothing to do with Pharo, OmniBrowser or Polymorph.
>>
>> This is PackageInfo that is so slow when trying to find out the  
>> owning
>> package of each of the 6334 methods. If the display of the package  
>> for
>> every method is removed the sender browser opens almost instantly.
>>
>> Lukas
>>
>>
> Hmmm, really? I do have a fast machine, and it ran in 1,7 seconds  
> for me, but when I run TimeProfileBrowser on the block (first time,  
> later runs alot of stuff is already cached and thus won't show up as  
> prominently if you do TimeProfile on opening a batch of windows ), I  
> get the following percentages:
> - 32% building the dynamic "all" category
>     - 19% reading all subclass selectors (these are then cached).
>     - 13% reading the timestamp of the compiledMethods /(these are  
> then cached) from sources to see if they're recent
> - 20% finding extension classes, amongst other things PackageInfo  
> here spends half that time doing an includes: check with an  
> OrderedCollection with 174 elements...
> -41% building the OB UI.
> -7% GC'ing
>
> A good increase in response time could probably be seen by, as you  
> said, not selecting all category by default, instead promising of  
> it's calculation (In VisualWorks anyways, for those who don't know,  
> it's the same as a fork which returns a value, but blocks if the  
> value it attempted to be used before it's finished calculated).
>
> 2 small Performance "bugs" I encountered while checking the methods:
> OBPackagesOrClassNode>>addUnpackagedCategories: categories to: pkgs  
> does:
>     SystemOrganization categories asSet difference: categories
> Looking at what the includes check in difference: is done against,  
> it's clear the code should be:
>     SystemOrganization categories difference: categories asSet.
> Difference: 500 repetitions in the debugger I had open at the time:  
> 10866 ms vs 581 ms. (20 times faster)
>
> PackageInfo >> externalClasses
> reads:
>     myClasses := self classesAndMetaClasses.
> then does an includes: check, could add an asSet on end there:
>     myClasses := self classesAndMetaClasses asSet.
> Difference: 500 repetitions in the debugger I had open at the time:  
> 105444ms vs  11447 ms (9 times faster)
>
> With these 2 changes, the 20% in finding extension classes was  
> reduced to 11%.
>
> Cheers,
> Henry
>
>
>
> <UseSetForIncludes.
> 1.cs>_______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> Cheers,
> Henry
>
> On 11.07.2009 09:10, Stéphane Ducasse wrote:
>>
>> Thanks henrik I will have a look at that.
>> If sombody else want to try and comment.
>> It would be great!
>>
>>
>> Stef
>>
>> On Jul 10, 2009, at 10:55 AM, Henrik Sperre Johansen wrote:
>>
>>
>>> On 09.07.2009 23:03, Lukas Renggli wrote:
>>>
>>>>> OUCH!!!!  That's quite an example; just for giggles, I started up
>>>>> a 3.9 polymorph image and retraced my steps (via message names,
>>>>> same as in Pharo) and  had a prompt reply.  After doing that, I
>>>>> found that Pharo (win32) had indeed completed the task.
>>>>>
>>>>>
>>>> Again, this has nothing to do with Pharo, OmniBrowser or Polymorph.
>>>>
>>>> This is PackageInfo that is so slow when trying to find out the
>>>> owning
>>>> package of each of the 6334 methods. If the display of the package
>>>> for
>>>> every method is removed the sender browser opens almost instantly.
>>>>
>>>> Lukas
>>>>
>>>>
>>>>
>>> Hmmm, really? I do have a fast machine, and it ran in 1,7 seconds
>>> for me, but when I run TimeProfileBrowser on the block (first time,
>>> later runs alot of stuff is already cached and thus won't show up as
>>> prominently if you do TimeProfile on opening a batch of windows ), I
>>> get the following percentages:
>>> - 32% building the dynamic "all" category
>>>     - 19% reading all subclass selectors (these are then cached).
>>>     - 13% reading the timestamp of the compiledMethods /(these are
>>> then cached) from sources to see if they're recent
>>> - 20% finding extension classes, amongst other things PackageInfo
>>> here spends half that time doing an includes: check with an
>>> OrderedCollection with 174 elements...
>>> -41% building the OB UI.
>>> -7% GC'ing
>>>
>>> A good increase in response time could probably be seen by, as you
>>> said, not selecting all category by default, instead promising of
>>> it's calculation (In VisualWorks anyways, for those who don't know,
>>> it's the same as a fork which returns a value, but blocks if the
>>> value it attempted to be used before it's finished calculated).
>>>
>>> 2 small Performance "bugs" I encountered while checking the methods:
>>> OBPackagesOrClassNode>>addUnpackagedCategories: categories to: pkgs
>>> does:
>>>     SystemOrganization categories asSet difference: categories
>>> Looking at what the includes check in difference: is done against,
>>> it's clear the code should be:
>>>     SystemOrganization categories difference: categories asSet.
>>> Difference: 500 repetitions in the debugger I had open at the time:
>>> 10866 ms vs 581 ms. (20 times faster)
>>>
>>> PackageInfo >> externalClasses
>>> reads:
>>>     myClasses := self classesAndMetaClasses.
>>> then does an includes: check, could add an asSet on end there:
>>>     myClasses := self classesAndMetaClasses asSet.
>>> Difference: 500 repetitions in the debugger I had open at the time:
>>> 105444ms vs  11447 ms (9 times faster)
>>>
>>> With these 2 changes, the 20% in finding extension classes was
>>> reduced to 11%.
>>>
>>> Cheers,
>>> Henry
>>>
>>>
>>>
>>> <UseSetForIncludes.
>>> 1.cs>_______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Henrik Sperre Johansen wrote:
>> On 09.07.2009 23:03, Lukas Renggli wrote:
>>>> OUCH!!!!  That's quite an example; just for giggles, I started up  
>>>> a 3.9 polymorph image and retraced my steps (via message names,  
>>>> same as in Pharo) and  had a prompt reply.  After doing that, I  
>>>> found that Pharo (win32) had indeed completed the task.
>>>>
>>>
>>> Again, this has nothing to do with Pharo, OmniBrowser or Polymorph.
>>>
>>> This is PackageInfo that is so slow when trying to find out the  
>>> owning
>>> package of each of the 6334 methods. If the display of the package  
>>> for
>>> every method is removed the sender browser opens almost instantly.
>>>
>>> Lukas
>>>
>>>
> I don't know if this helps but in MC1.5 Matthew sped up the  
> PackageInfo
> routines for scanning the image by a factor of 10 or so.
>
> Keith
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project