Issue 1634: Object allSubInstances slooooow
Locked
Issue 1634: Object allSubInstances slooooow
 
|
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: Test also attached (it's slow without the mod) http://code.google.com/p/pharo/issues/detail?id=1634 BehaviorTest-testAllObjectsPerformance.stBehavior-allSubInstancesDo.st Behavior-allSubInstancesDo.st |
Re: Issue 1634: Object allSubInstances slooooow
|
|
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. Regards, -Martin _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 1634: Object allSubInstances slooooow
|
|
On Fri, Dec 18, 2009 at 6:04 PM, Martin McClure <[hidden email]> wrote:
+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.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 1634: Object allSubInstances slooooow
|
|
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" Yes. It doesn't currently, but it could. See comment above. 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 Behavior-allSubInstancesDoInOnePass.st |
Re: Issue 1634: Object allSubInstances slooooow
|
|
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 >> <[hidden email]>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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 1634: Object allSubInstances slooooow
|
|
In reply to this post by Stan Shepherd
On Sat, Dec 19, 2009 at 9:11 AM, Stan Shepherd <[hidden email]> wrote:
Sorry Sam :) I had to be blunt. I knew you'd understand :) Forgive me.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 1634: Object allSubInstances slooooow
|
|
In reply to this post by Stéphane Ducasse
SpaceTally uses allInstances for each class. [(SpaceTally new systemWideSpaceTally asSortedCollection: [:a :b | a spaceForInstances > b spaceForInstances]) asArray inspect] timeToRun 363332 on a slow machine. Could probably be made somewhat faster by keeping a count of all classes' instances during one pass. Senders of allSubInstances with their number of subclasses ---------------------------------------------------------- a MethodReference Behavior >> #inspectSubInstances->3396 a MethodReference Morph class >> #morphsUnknownToTheirOwners->221 a MethodReference Morph >> #morphsUnknownToTheirOwners->221 a MethodReference Set class >> #rehashAllSets->21 a MethodReference Set >> #rehashAllSets->21 a MethodReference UITheme class >> #closeExampleDialogs->6 a MethodReference UITheme >> #closeExampleDialogs->6 a MethodReference FT2Handle class >> #shutDown:->5 a MethodReference FT2Handle >> #shutDown:->5 a MethodReference Categorizer class >> #sortAllCategories->4 a MethodReference Categorizer >> #sortAllCategories->4 a MethodReference TTCFont class >> #recreateCache->2 a MethodReference TTCFont >> #recreateCache->2 a MethodReference Symbol class >> #rehash->2 a MethodReference Symbol >> #rehash->2 a MethodReference StrikeFont class >> #setupDefaultFallbackFont->2 a MethodReference StrikeFont >> #setupDefaultFallbackFont->2 a MethodReference WAProcessStatus >> #processes->0 a MethodReference Utilities class >> #closeAllDebuggers->0 a MethodReference Utilities >> #closeAllDebuggers->0 ...etc Morph morphsUnKnownToTheirOwners timeToRun is 10s; could be faster, but has no senders. Senders of allSubInstancesDo: with their number of subclasses ---------------------------------------------------------- a MethodReference Behavior >> #allSubInstances->3396 a MethodReference Behavior >> #allInstancesEverywhereDo:->3396 a MethodReference ClassDescription >> #updateInstancesFrom:->3395 a MethodReference WASqueakStatusItem >> #numberOfSessions->8 a MethodReference MCFileBasedRepository class >> #flushAllCaches->5 a MethodReference MCFileBasedRepository >> #flushAllCaches->5 a MethodReference PopUpMenu class >> #setMenuFontTo:->3 a MethodReference PopUpMenu class >> #initialize->3 a MethodReference PopUpMenu >> #setMenuFontTo:->3 a MethodReference PopUpMenu >> #initialize->3 a MethodReference ChangeList >> #selectConflictsWith->3 a MethodReference TTCFont class >> #initialize->2 a MethodReference TTCFont >> #initialize->2 a MethodReference StrikeFont class >> #shutDown->2 a MethodReference StrikeFont >> #shutDown->2 a MethodReference WARegistry class >> #clearAll->1 a MethodReference WARegistry >> #clearAll->1 a MethodReference ShortIntegerArray class >> #swapShortObjects->1 a MethodReference ShortIntegerArray >> #swapShortObjects->1 a MethodReference Preferences class >> #smartUpdatingChanged->1 a MethodReference Preferences class >> #setFlapsFontTo:->1 ...etc Metaclass is the sole sender of allInstancesEverywhereDo: Conclusion- there are no cases which clearly need attention, with the possible exception of Object>>allSubInstances It might be worth catching calls to #allSubInstances, #allSubInstancesDo: where subclasses size > say 100, as Martin mentioned. |
Re: Issue 1634: Object allSubInstances slooooow
|
|
In reply to this post by Eliot Miranda-2
No worries, it made me laugh. I do have a question out of it though. Is there a conceivable situation where you would want Object class to have specific behaviour? If so, as Object class carries the role of backstop case where other classes don't define a method, is there any acceptable way to treat Object class differently? ...Stan |
Re: Issue 1634: Object allSubInstances slooooow
|
|
>>>>> "Stan" == Stan Shepherd <[hidden email]> writes:
Stan> Eliot Miranda-2 wrote: >> >> >> Sorry Sam :) I had to be blunt. I knew you'd understand :) >> >> Stan> No worries, it made me laugh. Stan> I do have a question out of it though. Is there a conceivable situation Stan> where you would want Object class to have specific behaviour? If so, as Stan> Object class carries the role of backstop case where other classes don't Stan> define a method, is there any acceptable way to treat Object class Stan> differently? allSubinstances self == Object ifTrue: [^self allSubinstancesSpecialCasedForObject]. ^super allSubinstances -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Issue 1634: Object allSubInstances slooooow
|
|
In reply to this post by Stan Shepherd
On Mon, Dec 21, 2009 at 7:18 AM, Stan Shepherd <[hidden email]> wrote:
In general I don't think so. I think it is wrong to assume Object is the root. Squeak currently assumes ProtoObject is the root. In VisualWorks there is a special method rootsOfTheWorld which answers the roots. Smalltalk allows one to create classes that don't inherit form anything else and that is very useful for creating encapsulators. Special casing Object or ProtoObject will break these uses.
However, if you were to package up some application in which you knew there would never exist subclasses other than Object, and the performance of allSubInstances was important you would go right ahead and apply that patch.
So not in the base, but in a specific app, sure. best Eliot
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |