>> 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.
David
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
