2009/2/10 David Röthlisberger <squeak@webcitas.ch>:
As for, 3.3% {2ms} ByteString class(String class)>>new:
Total count of ByteString>>new: calls during GlobalCounter reset. self fullDrawOn: World assuredCanvas. GlobalCounter counters copy inspect
is 7146, which again makes me look suspicious at OB here.. Hey! Are we drawing, or processing a text?!?!
hehe, good point. The reason why OB does heavy string processing is, simply said, that packages and class categories are not first class, but stupid strings... To for instance find out to which Monticello package a class cat belongs (or vice-versa) we have to do string processing, to not show the package name of a class cat (eg. 'Kernel-Classes' are displayed as 'Classes' in the tree below package 'Kernel') we have to do string processing, and so on, and so on. As there are many packages with many class cats, this sums up.
So if we had real packages in Pharo as first class entities, OB would be much faster and simpler to maintain. Right now, OB models packages and class cats itself, has to take the information from both the Monticello's working copy managers and the SystemOrganizer. This is a mess and a huge pain, but what can we do. We should really invest in bringing real packages to Pharo.
Right, i had an impression, that so much string processing going from the need to build a tree from class category names. But again, there is no excuse in doing this each time you need a tree. Thanks to system notifier we have a ways to determine when category tree needs to be rebuilt, so it can be built once and stay cached until user add/remove/rename category.
David
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.