[Pharo-dev] Large images reasons [WAS] Re: [Pharo-users] Pharo 2.0 with Seaside + DBXTalk + GlorpDBX + Magritte 3 + TWBS is getting slower and slower

Stéphane Ducasse stephane.ducasse at inria.fr
Thu Aug 1 02:56:01 EDT 2013


since years marcus is telling that MC storing ancestor information is doomed but we do not have something to really replace it.

Stef
On Jul 31, 2013, at 8:53 PM, Mariano Martinez Peck <marianopeck at 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 at 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 at inria.fr> wrote:
> 
> On Jul 30, 2013, at 1:49 PM, "phil at highoctane.be" <phil at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20130801/4ada8991/attachment-0002.html>


More information about the Pharo-dev mailing list