Stan did you compare/have a look at spaceTally because it is also reporting memory consumption and may be we could make everything better. (I just read my mails between two houses fixes). I will take more time this evening if I can. Anyway thanks. I like these kinds of discussions. Because I learn stuff or they make me think and rethink what I think I know
Stef On Dec 19, 2009, at 6:11 PM, Stan Shepherd 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 ;) > > > 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
