Phil, and the cleanUpForRelease in general does not help at all?
On Wed, Jul 31, 2013 at 8:30 PM, [email protected] <[email protected]>wrote: > Doing the flushCaches... > > Image size before cleaning a MCSmalltalkhubRepository( > http://smalltalkhub.com/mc/estebanlm/EclipsePack/main/) : 324017564 > Image size after cleaning a MCSmalltalkhubRepository( > http://smalltalkhub.com/mc/estebanlm/EclipsePack/main/) : 324137232 > Image size before cleaning a MCSmalltalkhubRepository( > http://smalltalkhub.com/mc/philippeback/DripfeedIt/main/) : 324137232 > Image size after cleaning a MCSmalltalkhubRepository( > http://smalltalkhub.com/mc/philippeback/DripfeedIt/main/) : 324195720 > Image size before cleaning a MCSmalltalkhubRepository( > http://smalltalkhub.com/mc/philippeback/HOWebStack/main/) : 324195720 > Image size after cleaning a MCSmalltalkhubRepository( > http://smalltalkhub.com/mc/philippeback/HOWebStack/main/) : 324255300 > Image size before cleaning a MCSmalltalkhubRepository( > http://smalltalkhub.com/mc/philippeback/HOExperiments/main/) : 324255300 > Image size after cleaning a MCSmalltalkhubRepository( > http://smalltalkhub.com/mc/philippeback/HOExperiments/main/) : 324314868 > > Definitely not going down... > > Phil > > > > On Wed, Jul 31, 2013 at 8:53 PM, Mariano Martinez Peck < > [email protected]> wrote: > >> OK, this was was my experiment.... >> >> Image fresh with all my app and dependencies loades: 30MB >> >> After using it for some days/weeks: 160MB. >> >> SpaceTally new printSpaceAnalysis showed: >> >> Class code space # instances >> inst space percent inst average size >> ByteString 2785 413144 >> 116244078 69.90 281.36 >> Array 3712 181772 >> 8466668 5.10 46.58 >> ByteArray 8574 1319 >> 8186802 4.90 6206.82 >> Bitmap 3653 303 >> 6656340 4.00 21968.12 >> CompiledMethod 22467 90554 >> 5685374 3.40 62.78 >> >> >> After executing ImageCleaner cleanUpForRelease: 36MB >> >> Then...I searched which part of #cleanUpForRelease: was making the >> difference, and it was: >> >> Smalltalk cleanUp: true except: #() confirming: false. >> >> So now it was time to know WHICH class did the diference, so I modified >> #cleanUp: aggressive except: exclusions confirming: aBool >> >> in these lines: >> >> "Run the cleanup code" >> classes >> do:[:aClass| >> Transcript show: 'Image size before cleaning ', aClass name, ' : ', >> Smalltalk imagePath asFileReference size asString. >> aClass cleanUp: aggressive. >> 3 timesRepeat: [Smalltalk garbageCollect]. >> Smalltalk snapshot: true andQuit: false. >> Transcript show: 'Image size after cleaning ', aClass name, ' : ', >> Smalltalk imagePath asFileReference size asString. >> ] >> displayingProgress: [:aClass| 'Cleaning up in ', aClass name]. >> I then opened a Transcript, and evaluated >> >> Smalltalk cleanUp: true except: #() confirming: false. >> >> I went to prepare Mate, and when I come back, the result was, of course: >> >> "Image size after cleaning MCFileBasedRepository : 39744008" >> >> That clean up ends up doing: >> >> flushAllCaches >> self allSubInstancesDo: [:ea | ea flushCache] >> So it sends #flushCache to all instances of MCHttpRepository and >> MCFileBasedRepository. >> >> Now what I wanted to see if it there was a particular repo that could >> take most of the space (like package-cache). >> And indeed, it was...I modified #flushCaches to: >> >> flushAllCaches >> | file | >> file := 'repos.txt' asFileReference writeStream text. >> self allSubInstancesDo: [:each | >> file nextPutAll: 'Image size before cleaning ', each printString, ' : >> ', Smalltalk imagePath asFileReference size asString; cr. >> each flushCache. >> 3 timesRepeat: [Smalltalk garbageCollect]. >> Smalltalk snapshot: true andQuit: false. >> file nextPutAll: 'Image size after cleaning ', each printString, ' : ', >> Smalltalk imagePath asFileReference size asString;cr. >> ]. >> file flush; close. >> And then I looked in the 'repos.txt' file. My package cache repo cleaned >> 60 MB. Glorp cleaned 35MB. Seaside30 cleaned 10MB. >> So...cleaning cache of just 3 repos frees approx 100MB. >> >> The question is....can we flush the cache safely? If they are called >> "cache", then I guess yes, we can. >> >> Thoughts? >> >> Thanks, >> >> >> >> On Wed, Jul 31, 2013 at 10:48 AM, Mariano Martinez Peck < >> [email protected]> wrote: >> >>> Guys, I have images also with seaside, magritte, glorp, postgresV2, etc >>> and it is also around 200MB. >>> I will try to do some research today and let you know. >>> >>> Cheers, >>> >>> >>> On Tue, Jul 30, 2013 at 8:55 AM, Marcus Denker >>> <[email protected]>wrote: >>> >>>> >>>> On Jul 30, 2013, at 1:49 PM, "[email protected]" <[email protected]> >>>> wrote: >>>> >>>> > the changes file contained passwords and I replaced the text. So >>>> offsets may be wrong due to that. >>>> > >>>> Yes, the first thing I wanted to do is to recompile everything. Does >>>> not work. >>>> >>>> > Memorymonitor is not doing fanct stuff. It just counts instances. >>>> > >>>> Yes, but maybe it holds on to these instances? >>>> >>>> Marcus >>>> >>>> >>>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > -- Mariano http://marianopeck.wordpress.com
