Hi,
Starting playing with Croquet, I've created a new version of the actual official image to play a bit and its size has grown very quickly (about 2 or 3 times bigger). I don't really understand why, I've just created some new classes to define my own islands and I believe that the objects created are well destroyed. Is there a way to discover what takes so much memory in the image ? (dead objects, ...) Thanks, Jérôme |
Take a look at the class "SpaceTally".
Josh On May 10, 2007, at 3:08 PM, Jérôme Fuselier wrote: > Hi, > Starting playing with Croquet, I've created a new version of the > actual official image to play a bit and its size has grown very > quickly (about 2 or 3 times bigger). I don't really understand why, > I've just created some new classes to define my own islands and I > believe that the objects created are well destroyed. Is there a way > to discover what takes so much memory in the image ? (dead > objects, ...) > > > Thanks, > Jérôme |
In reply to this post by Jerome Fuselier
Dear Jérôme,
I have the same problem with my Croquet images. I believe the problem is discussed in the following thread: https://lists.duke.edu/sympa/arc/croquet-dev/2006-10/msg00014.html The silly solution that we use is to click on the morphic desktop with the yellow mouse button (option+click on the Mac) and add a few menu items to the menu: aMenu add: 'Clear TestingScriptRegistry' target: TestingScriptRegistry action: #removeUnreferencedKeys. aMenu addLine. aMenu add: 'Empty Trash Can' translated target: Utilities action: #emptyScrapsBook. aMenu add: 'Clear Command History' target: CommandHistory action: #resetAllHistory. aMenu add: 'Collect Garbage' target: Smalltalk action: #garbageCollect. aMenu addLine. I then run these before I save my image to clean up any hanging references which will bloat my image. Hope this helps, Liz Wendland University of MN Jérôme Fuselier wrote: > Hi, > Starting playing with Croquet, I've created a new version of the > actual official image to play a bit and its size has grown very > quickly (about 2 or 3 times bigger). I don't really understand why, > I've just created some new classes to define my own islands and I > believe that the objects created are well destroyed. Is there a way to > discover what takes so much memory in the image ? (dead objects, ...) > > > Thanks, > Jérôme |
A few other snippets that are useful... Some of these may not apply, depending on the exact vintage of your Croquet: TIslandController initialize. TIslandController allInstancesDo: [ :i | i destroy ]. TContactPoint allInstancesDo: [ :i | i destroy ]. TFarRef initialize. TFormManager default: nil. TSessionDispatcher reset. Debug windows can occasionally get stuck hidden inside the morphic worlds behind embedded applications, and they hang on to whole croquet sessions in memory... PreDebugWindow allInstancesDo: [ :w|w closeButtonHit]. These are often helpful - monticello is greedy... MCFileBasedRepository flushAllCaches. MCDefinition clearInstances. And this occasionally can recover a lot of space... but note that it obliterates all but the active change set. (If you use MC a lot, change sets can pile up.) ChangeSet allInstances do:[:cs| cs == ChangeSet current ifFalse:[ChangeSet removeChangeSet: cs]]. I do all of these, and all of Liz's suggestions, in a single Morphic script that I have hooked to a button on my desktop. - brad > Dear Jérôme, > > I have the same problem with my Croquet images. I believe the > problem is discussed in the following thread: > > https://lists.duke.edu/sympa/arc/croquet-dev/2006-10/msg00014.html > > The silly solution that we use is to click on the morphic desktop > with the yellow mouse button (option+click on the Mac) and add a > few menu items to the menu: > > aMenu add: 'Clear TestingScriptRegistry' target: > TestingScriptRegistry action: #removeUnreferencedKeys. > aMenu addLine. > aMenu add: 'Empty Trash Can' translated target: Utilities > action: #emptyScrapsBook. > aMenu add: 'Clear Command History' target: CommandHistory > action: #resetAllHistory. > aMenu add: 'Collect Garbage' target: Smalltalk action: > #garbageCollect. aMenu addLine. > > I then run these before I save my image to clean up any hanging > references which will bloat my image. > > Hope this helps, > Liz Wendland > University of MN > > Jérôme Fuselier wrote: >> Hi, >> Starting playing with Croquet, I've created a new version of the >> actual official image to play a bit and its size has grown very >> quickly (about 2 or 3 times bigger). I don't really understand >> why, I've just created some new classes to define my own islands >> and I believe that the objects created are well destroyed. Is >> there a way to discover what takes so much memory in the image ? >> (dead objects, ...) >> >> >> Thanks, >> Jérôme > |
As long as we're collecting favorite image-slimming stuff...
Some comments are interspersed below. In addition, these are useful when you're preparing a clean image for distribution to others (rather than just for your own development use): Smalltalk cleanOutUndeclared. Smalltalk removeEmptyMessageCategories. Symbol rehash. Smalltalk flushClassNameCache. 3 timesRepeat: [Smalltalk garbageCollect. Symbol compactSymbolTable]. and if you're so inclined: Island classPool at: #Default put: nil. KLiveAudioSource clearSingleton. KLiveVideoSource clearSingleton. Some of this is lore that probably wouldn't stand up to scrutiny, and some ought to be automated (maybe with addToShutDownList:..?). That would be a nice little project ... On May 12, 2007, at 9:39 PM, brad fowlow wrote: > > A few other snippets that are useful... > > Some of these may not apply, depending on the exact vintage of your > Croquet: > > TIslandController initialize. > TIslandController allInstancesDo: [ :i | i destroy ]. > TContactPoint allInstancesDo: [ :i | i destroy ]. > TFarRef initialize. > TFormManager default: nil. > TSessionDispatcher reset. > > Debug windows can occasionally get stuck hidden inside > the morphic worlds behind embedded applications, > and they hang on to whole croquet sessions in memory... > > PreDebugWindow allInstancesDo: [ :w|w closeButtonHit]. > > > These are often helpful - monticello is greedy... I sometimes precede the following with: MCMethodDefinition shutDown. > > MCFileBasedRepository flushAllCaches. > MCDefinition clearInstances. > > > And this occasionally can recover a lot of space... > but note that it obliterates all but the active change set. > (If you use MC a lot, change sets can pile up.) > > ChangeSet allInstances do:[:cs| > cs == ChangeSet current > ifFalse:[ChangeSet removeChangeSet: cs]]. I do this instead (which isn't really the same thing): Smalltalk condenseChanges. > > I do all of these, and all of Liz's suggestions, > in a single Morphic script that I have hooked to a button on my > desktop. > > - brad > > > >> Dear Jérôme, >> >> I have the same problem with my Croquet images. I believe the >> problem is discussed in the following thread: >> >> https://lists.duke.edu/sympa/arc/croquet-dev/2006-10/msg00014.html >> >> The silly solution that we use is to click on the morphic desktop >> with the yellow mouse button (option+click on the Mac) and add a >> few menu items to the menu: >> >> aMenu add: 'Clear TestingScriptRegistry' target: >> TestingScriptRegistry action: #removeUnreferencedKeys. >> aMenu addLine. >> aMenu add: 'Empty Trash Can' translated target: Utilities >> action: #emptyScrapsBook. >> aMenu add: 'Clear Command History' target: CommandHistory >> action: #resetAllHistory. Some related things to #resetAllHistory, but not quite the same are: Smalltalk forgetDoIts. Smalltalk cleanUpUndoCommands. >> aMenu add: 'Collect Garbage' target: Smalltalk action: >> #garbageCollect. aMenu addLine. >> >> I then run these before I save my image to clean up any hanging >> references which will bloat my image. >> >> Hope this helps, >> Liz Wendland >> University of MN >> >> Jérôme Fuselier wrote: >>> Hi, >>> Starting playing with Croquet, I've created a new version of the >>> actual official image to play a bit and its size has grown very >>> quickly (about 2 or 3 times bigger). I don't really understand >>> why, I've just created some new classes to define my own islands >>> and I believe that the objects created are well destroyed. Is >>> there a way to discover what takes so much memory in the image ? >>> (dead objects, ...) >>> >>> >>> Thanks, >>> Jérôme >> > |
Free forum by Nabble | Edit this page |