Thanks henrik Probably the package browser is doing too much stuff too. I'm slowly making progress on the new package class (test driven) 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
