I'll give a shot at trying that on my 300 megs thing!

Learning ahead!

On Wednesday, July 31, 2013, Mariano Martinez Peck <marianopeck@gmail.com> 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 <marianopeck@gmail.com> 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 <marcus.denker@inria.fr> wrote:
>>>
>>> On Jul 30, 2013, at 1:49 PM, "phil@highoctane.be" <phil@highoctane.be> 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
>

--
---
Philippe Back
Dramatic Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Mail:phil@highoctane.be | Web: http://philippeback.eu
Blog: http://philippeback.be | Twitter: @philippeback
Youtube: http://www.youtube.com/user/philippeback/videos

High Octane SPRL
rue cour Boisacq 101 | 1301 Bierges | Belgium

Featured on the Software Process and Measurement Cast
http://spamcast.libsyn.com
Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
�