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