[Pharo-project] Image size
Hi, I have problems in understanding the image size of pharo. I monitored it since we started and I did not recognize a notably change. So I took a pharo 10073 and squeak 3.10.2 for comparsion. Amount classes, amount methods and lines of code are all 10% less in pharo. But the image is approx. 0,5% - 1% smaller than the squeak one. To clarify this. I closed all windows and did condenseChanges and garbageCollect, flushed the monticello cache... What could be the reason for this? thanks, Norbert
did you flush the changesets ? because it keeps a reference also to any changes. Stef On Sep 19, 2008, at 10:36 AM, Norbert Hartl wrote:
Hi,
I have problems in understanding the image size of pharo. I monitored it since we started and I did not recognize a notably change. So I took a pharo 10073 and squeak 3.10.2 for comparsion.
yes frustrating after removing MVC and more.
Amount classes, amount methods and lines of code are all 10% less in pharo. But the image is approx. 0,5% - 1% smaller than the squeak one.
To clarify this. I closed all windows and did condenseChanges and garbageCollect, flushed the monticello cache...
What could be the reason for this?
thanks,
Norbert
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Fri, 2008-09-19 at 10:42 +0200, Stéphane Ducasse wrote:
did you flush the changesets ? because it keeps a reference also to any changes.
Ah, learned something new :) That freed more than 1 megabyte. So it is 5% smaller than squeak. Any other hints? :) thanks, Norbert
Stef
On Sep 19, 2008, at 10:36 AM, Norbert Hartl wrote:
Hi,
I have problems in understanding the image size of pharo. I monitored it since we started and I did not recognize a notably change. So I took a pharo 10073 and squeak 3.10.2 for comparsion.
yes frustrating after removing MVC and more.
Amount classes, amount methods and lines of code are all 10% less in pharo. But the image is approx. 0,5% - 1% smaller than the squeak one.
To clarify this. I closed all windows and did condenseChanges and garbageCollect, flushed the monticello cache...
What could be the reason for this?
thanks,
Norbert
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 19.09.2008, at 10:42, Stéphane Ducasse wrote:
did you flush the changesets ?
That's important. Adrian lienhard sent this around some time ago some cleanup code. Here is an updated version: ScriptLoader new cleaningCS. RequiredSelectors initialize. ProvidedSelectors initialize. LocalSends initialize. Utilities cleanseOtherworldlySteppers. Smalltalk organization removeEmptyCategories. SystemBrowser removeObsolete. TheWorldMenu removeObsolete. AppRegistry removeObsolete. MCFileBasedRepository flushAllCaches. MCDefinition clearInstances. Symbol compactSymbolTable. Set rehashAllSets. Smalltalk cleanOutUndeclared. Smalltalk garbageCollect. --> 13.7 MB 3.9 was 15.6 MB There is more code for cleaning in the "cleaning" category of ScriptLoader. #initialCleanup and #finalCleanup. (we should merge the code above in the cleanup methods) The changesets are the majority of the space, another 100K or so comes from rehashing the sets. This is I think because the methodDictionaries are degenerating very fast when adding / replacing methods. Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
On Fri, 2008-09-19 at 11:06 +0200, Marcus Denker wrote:
On 19.09.2008, at 10:42, Stéphane Ducasse wrote:
did you flush the changesets ?
That's important. Adrian lienhard sent this around some time ago some cleanup code. Here is an updated version:
ScriptLoader new cleaningCS. RequiredSelectors initialize. ProvidedSelectors initialize. LocalSends initialize. Utilities cleanseOtherworldlySteppers. Smalltalk organization removeEmptyCategories. SystemBrowser removeObsolete. TheWorldMenu removeObsolete. AppRegistry removeObsolete. MCFileBasedRepository flushAllCaches. MCDefinition clearInstances. Symbol compactSymbolTable. Set rehashAllSets. Smalltalk cleanOutUndeclared. Smalltalk garbageCollect.
--> 13.7 MB 3.9 was 15.6 MB
There is more code for cleaning in the "cleaning" category of ScriptLoader. #initialCleanup and #finalCleanup. (we should merge the code above in the cleanup methods)
The changesets are the majority of the space, another 100K or so comes from rehashing the sets. This is I think because the methodDictionaries are degenerating very fast when adding / replacing methods.
I had a look at it and SMSqueakMap default clearCaches. might be a candidate to add. Is there a reason why the cleanup code resides in ScriptLoader? Norbert
On 19.09.2008, at 11:19, Norbert Hartl wrote:
SMSqueakMap default clearCaches.
might be a candidate to add.
SMSqueakMap default purge --> 12.2MB that is, SqueakMap keep 1.5MB of data in the image. We should remove it.
Is there a reason why the cleanup code resides in ScriptLoader?
No. -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
Marcus Denker wrote:
There is more code for cleaning in the "cleaning" category of ScriptLoader. #initialCleanup and #finalCleanup. (we should merge the code above in the cleanup methods)
There is also some code in the ReleaseBuilder classes. It would be good IMHO to have one location to put all these utility methods. I started ReleaseBuilder back then as that place, so subclasses e.g. for Squeakland, Sophie or Plopp can implement all the necessary magic needed when auto building a release. Michael
ScriptLoader is also such releaseBuilder guy. I know well releaseBuilder :) Stef
Is there a reason why the cleanup code resides in ScriptLoader?
No. -- But where you will put it?
Should have read all the mails first ;-) ReleaseBuilder
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Marcus Denker -
Michael Rueger -
Norbert Hartl -
Stéphane Ducasse