On Jul 11, 2009, at 1:15 PM, Henrik Sperre Johansen wrote:

> There's a changeset attached with those two, if you didn't notice ;)
> Behaviour is sort of an extreme class, results for others might vary.
>
> Also, I'm a bit of a loss what to do when submitting change  
> proposals to Pharo Dev, where there are lots of "external" packages,  
> and I have no idea who the current maintainers of affected packages  
> are...

I passed the info to david and this is integrated to OB
I will integrate the PackageInfo part in the next release (now I'm  
exhausted).
Stef
>
> 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
>>> [email protected]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to