On Sat, Dec 19, 2009 at 9:11 AM, Stan Shepherd <[email protected]>wrote:
> > > Eliot Miranda-2 wrote: > > > > On Fri, Dec 18, 2009 at 6:04 PM, Martin McClure > > <[email protected]>wrote: > > > >> Stan Shepherd wrote: > >> > Pharo image: Pharo | Pharo-core > >> > PharoCore1.0rc1 Latest update: #10502 > >> > VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: > >> > #10074] > >> > > >> > Steps to reproduce: > >> > 1.[Object allSubInstances size inspect] timeToRun 375479 (6 minutes) > >> > > >> > with fix > >> > [Object allSubInstances size inspect] timeToRun 22335 (22 seconds) > >> > > >> > Attached treats Object as a special case, and takes advantage of > >> primitive > >> > in SystemNavigation>>allObjectsDo: > >> > >> It looks like with this change, Object allSubInstances would return > >> instances of classes that do not inherit from Object, for instance > >> objects that inherit from ProtoObject. > >> > >> Perhaps the special case should go on ProtoObject? Or a test could be > >> made of how many subclasses a class has, and if it's over some arbitrary > >> number just iterate through all objects and test each one for isKindOf:? > >> Don't know how fast that would be, maybe it's not faster. But probably > >> slow is preferable to incorrect. If you just want "all objects" and > >> don't care about their class then you can always use > >> SystemNavigation>>allObjectsDo: rather than allSubInstances. > >> > > > > +1. > > > > I don't think there's any justification for this hack. It's possible to > > have another root to the hierarchy apart from ProtoObject. Further, a > bit > > weak, but allSubInstancesDo: has ordering properties; it will evaluate > the > > block with all instances of a class followed by all instances of another > > and > > so on; it will visit all instances of any superclass before it visits any > > instances of subclasses, and that could be useful. If you want to use > > allObjectsDo: use it. Of course allSubInstancesDo: is slow; it makes as > > many scans of the system as there are classes (Metaclass avoids the scan > > by > > evaluating with soleInstance). But that's not a justification for > > special-casing one use of it to a freely accessible but different > > alternative. > > > > > >> Regards, > >> > >> -Martin > >> > >> _______________________________________________ > >> 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 > > > > > Eliot Miranda-2 wrote: > > > > I don't think there's any justification for this hack. > > > > Quite so. It was late, and I'd thought better of it by morning. However, > don't feel you need to spare my feelings ;) > Sorry Sam :) I had to be blunt. I knew you'd understand :) Forgive me. > > Taking a step back, Object allSubinstances size seems to be a common proxy > measure for the size/bloat/complexity of an image. > (E.g. http://www.object-arts.com/docs/index.html?how_many_objects.htm ). > Running it on a large production system would potentially be very slow. > It could also be something a current Smalltaker would run to check out > Pharo, > in which case a coffee break would be warranted. So from a marketing of > Pharo > perspective, 6 minutes seems too long to me. Yes, an experienced user will > avoid it. > I have no proposal as to how to catch that case while avoiding a hack. > Adding a specific > allSubinstances to Object class would break inheritance chain to Behavior. > > > In the meantime, perhaps there should be an alternative simple measure > available: > > SystemNavigation>>allObjects > "A fast way to list all current objects in the image. > n.b. this will include the classes ImageSegmentRootStub > MessageCatcher > TestCoverage DynamicBindingsInfo, and possibly others, that do not > inherit from Object. These classes probably have no instances, but > it is not safe to assume this" > | aCollection | > aCollection := OrderedCollection new. > self allObjectsDo: > [:x | x == aCollection ifFalse: [aCollection add: x]]. > ^ aCollection > > with a comment in allSubInstances > "for Prototype>>allSubInstances, Object>>allSubInstances,consider > using > SystemNavigation>>allObjects. This is much faster. see comment > there" > > > Martin McClure wrote: > > > > It looks like with this change, Object allSubInstances would return > > instances of classes that do not inherit from Object, for instance > > objects that inherit from ProtoObject. > > > Yes. It doesn't currently, but it could. See comment above. > > > Martin McClure wrote: > > > > Or a test could be made of how many subclasses a class has, and if it's > > over some arbitrarynumber just iterate through all objects and test each > > one for isKindOf:? > > Don't know how fast that would be, maybe it's not faster. > > > Yes, I looked at that: > multi single > pass pass > Collection 18650 29448 82 subclasses, multipass 50% faster > > BorderedMorph 26301 7464 206 subclasses, singlepass 3x faster > > GRObject 113717 6969 742 subclasses, singlepass 14x faster. > > Breakeven point is around 100 subclasses. > > Mostly allSubInstances is used in housekeeping tasks, so it's not a big > issue. > As it's mostly used in housekeeping, a lot of the applications would > probably be > fine with the unordered, one pass version. > > I'll do a bit of digging into whether there are any meaningful performance > implications. > > ...Stan > > Behavior>>allSubInstancesDoInOnePass: attached if anyone wants to > benchmark > http://n2.nabble.com/file/n4192013/Behavior-allSubInstancesDoInOnePass.st > Behavior-allSubInstancesDoInOnePass.st > -- > View this message in context: > http://n2.nabble.com/Issue-1634-Object-allSubInstances-slooooow-tp4189848p4192013.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > 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
