Hi folks. I was playing a bit trying to shrink a little a PharoCore image. My idea was to think a shrink that was be acceptable for the most common scenario: a runtime (production) environment where. Of course, some of the things I do in the shrinks has side effects, but most of the times, you can deal with that in such scenarios.
Some of the things came from my mind, others from an OLD version of SystemDictionary >> majorShrink, others from Pavel's PharoKernel, etc. So...I will post the little code here. I am not completely sure about the side effects of each piece, so if you know, please let me know :) On the other hand, I wanted to ask you if you think something of this make sense to be part of ScriptLoader >> cleanUpForProduction Taking a PharoCore 1.1 11277 of 13 MB I get an image of 9 MB...so 4 MB less and I can still even browse code. When running the image before the shrink I get 25MB in use and with the image shrinked I get 20MB. Cheers Mariano "Compact all MethodDictionary instances" | oldInstances newInstances | oldInstances := MethodDictionary allInstances. newInstances := oldInstances collect: [ :md | (MethodDictionary new: md size) compactCopyFrom: md; yourself]. oldInstances elementsForwardIdentityTo: newInstances. "To put all all classes with the default category. Still can browse and recompile the whole image. Most production enviroments don't care about categories...this make sense when developing." Smalltalk allClassesAndTraitsDo: [:each | each zapOrganization ]. "Different cleanUps" TextStyle allSubInstancesDo: [:ts | ts newFontArray: (ts fontArray copyFrom: 1 to: (2 min: ts fontArray size))]. "Clean all Monticello related stuff. You won't be able to browse packages for example" MCWorkingCopyBrowser allInstancesDo: [:each | each flushAllCaches ]. MCWorkingCopy allInstancesDo:[:wc| SystemChangeNotifier uniqueInstance noMoreNotificationsFor: wc. wc unregister]. SystemChangeNotifier uniqueInstance noMoreNotificationsFor: MCPackageManager. SystemChangeNotifier uniqueInstance noMoreNotificationsFor: MCWorkingCopy. "Most application don't need sound" SoundService default: nil. SoundService unregister: DummySoundSystem. SystemChangeNotifier uniqueInstance noMoreNotificationsFor: (Smalltalk at: #RecentMessageSet). TranscriptStream newTranscript: ThreadSafeTranscript new. ImageSegment classPool at: #RecentlyRenamedClasses put: Dictionary new. ExternalSettings classPool at: #RegisteredClients put: Set new. Locale classPool at: #LocaleChangeListeners put: nil. "Clean all the changes" ChangeSet resetCurrentToNewUnnamedChangeSet. ChangeSet current initialize. ChangeSet classPool at: #AllChangeSets put: (OrderedCollection with: ChangeSet current). Symbol rehash. 3 timesRepeat: [ Smalltalk garbageCollect. Symbol compactSymbolTable ]. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
What I do on my build server is to unload the tests:
(MCWorkingCopy allManagers inject: Gofer new into: [ :gofer :each | ((each packageName endsWith: 'Test') or: [ each packageName endsWith: 'Tests' ]) ifTrue: [ gofer package: each packageName ]. gofer ]) unload. > Hi folks. I was playing a bit trying to shrink a little a PharoCore image. > My idea was to think a shrink that was be acceptable for the most common > scenario: a runtime (production) environment where. Of course, some of the > things I do in the shrinks has side effects, but most of the times, you can > deal with that in such scenarios. Shouldn't most of the code you publish be part of the <cleanup> protocol? Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Tue, Mar 23, 2010 at 10:19 AM, Lukas Renggli <[hidden email]> wrote: What I do on my build server is to unload the tests: ScriptLoader >> cleanUpForProduction do that but similary: #(#Tests #CollectionsTests #CompilerTests #FreeTypeTests #GraphicsTests #KernelTests #MorphicTests #MultilingualTests #NetworkTests #ToolsTest) do: [ :each | (MCPackage named: each) unload ]. "unload SUnit" Smalltalk globals at: #TestCase ifPresent: [ :class | SystemChangeNotifier uniqueInstance noMoreNotificationsFor: class ]. #(#SUnitGUI #SUnit) do: [ :each | (MCPackage named: each) unload ]. Maybe we you should change it ?
You refere to the "new" cleanUp protocol ? The thing is that not everything is a cleanUp, but a shrink. Suppose the code that zap all the organizations...that's not a cleanUp. So, maybe yes, but not all of them. Cheers Mariano Lukas _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Mariano Martinez Peck
Hi Mariano,
Great to see further progress on this! I'll take a closer look at your script this evening. But what I wonder is why PharoCore 1.1 is so big and you only get down to 9MB (is this the size on disk?)? In a PharoCore 1.0 running #cleanUpForRelease, #cleanUpForProduction, deleting the class ScriptLoader and all changesets I get an image that is 8.1MB on disk. Cheers, Adrian On Mar 23, 2010, at 10:15 , Mariano Martinez Peck wrote: > Hi folks. I was playing a bit trying to shrink a little a PharoCore image. > My idea was to think a shrink that was be acceptable for the most common > scenario: a runtime (production) environment where. Of course, some of the > things I do in the shrinks has side effects, but most of the times, you can > deal with that in such scenarios. > > Some of the things came from my mind, others from an OLD version of > SystemDictionary >> majorShrink, others from Pavel's PharoKernel, etc. > > So...I will post the little code here. I am not completely sure about the > side effects of each piece, so if you know, please let me know :) > > On the other hand, I wanted to ask you if you think something of this make > sense to be part of ScriptLoader >> cleanUpForProduction > > Taking a PharoCore 1.1 11277 of 13 MB I get an image of 9 MB...so 4 MB > less and I can still even browse code. > When running the image before the shrink I get 25MB in use and with the > image shrinked I get 20MB. > > Cheers > > Mariano > > > > > > "Compact all MethodDictionary instances" > > | oldInstances newInstances | > oldInstances := MethodDictionary allInstances. > newInstances := oldInstances collect: > [ :md | > (MethodDictionary new: md size) > compactCopyFrom: md; > yourself]. > > oldInstances elementsForwardIdentityTo: newInstances. > > > > "To put all all classes with the default category. Still can browse and > recompile the whole image. > Most production enviroments don't care about categories...this make sense > when developing." > > Smalltalk allClassesAndTraitsDo: [:each | each zapOrganization ]. > > > "Different cleanUps" > > TextStyle > allSubInstancesDo: [:ts | ts > newFontArray: (ts fontArray > copyFrom: 1 > to: (2 min: ts fontArray size))]. > > "Clean all Monticello related stuff. You won't be able to browse packages > for example" > > MCWorkingCopyBrowser allInstancesDo: [:each | each flushAllCaches ]. > MCWorkingCopy allInstancesDo:[:wc| SystemChangeNotifier uniqueInstance > noMoreNotificationsFor: wc. wc unregister]. > SystemChangeNotifier uniqueInstance noMoreNotificationsFor: > MCPackageManager. > SystemChangeNotifier uniqueInstance noMoreNotificationsFor: MCWorkingCopy. > > "Most application don't need sound" > > SoundService default: nil. > SoundService unregister: DummySoundSystem. > > SystemChangeNotifier uniqueInstance noMoreNotificationsFor: (Smalltalk at: > #RecentMessageSet). > > TranscriptStream newTranscript: ThreadSafeTranscript new. > > ImageSegment classPool at: #RecentlyRenamedClasses put: Dictionary new. > ExternalSettings classPool at: #RegisteredClients put: Set new. > > Locale classPool at: #LocaleChangeListeners put: nil. > > "Clean all the changes" > > ChangeSet resetCurrentToNewUnnamedChangeSet. > ChangeSet current initialize. > ChangeSet classPool > at: #AllChangeSets > put: (OrderedCollection with: ChangeSet current). > > Symbol rehash. > > 3 timesRepeat: [ Smalltalk garbageCollect. Symbol compactSymbolTable ]. > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Tue, Mar 23, 2010 at 10:29 AM, Adrian Lienhard <[hidden email]> wrote: Hi Mariano, I asked that myself. I even think I already asked that in mailing list. Honestly, I don't know. and you only get down to 9MB (is this the size on disk?)? yes.
yes. Ahh be aware....cleanUpForProduction in 1.1 is cool: he kill himself (unload the package ScriptLoader) at the end of the cleanUp ;)
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Mariano Martinez Peck
mariano
cleanUp: true support agrresive cleanup = "shrink" On Mar 23, 2010, at 10:24 AM, Mariano Martinez Peck wrote: > > > On Tue, Mar 23, 2010 at 10:19 AM, Lukas Renggli <[hidden email]> wrote: > What I do on my build server is to unload the tests: > > (MCWorkingCopy allManagers > inject: Gofer new > into: [ :gofer :each | > ((each packageName endsWith: 'Test') or: [ each > packageName endsWith: 'Tests' ]) > ifTrue: [ gofer package: each packageName ]. > gofer ]) > unload. > > > ScriptLoader >> cleanUpForProduction do that but similary: > > #(#Tests #CollectionsTests #CompilerTests #FreeTypeTests #GraphicsTests #KernelTests #MorphicTests #MultilingualTests #NetworkTests #ToolsTest) > do: [ :each | (MCPackage named: each) unload ]. "unload SUnit" > Smalltalk globals > at: #TestCase > ifPresent: [ :class | SystemChangeNotifier uniqueInstance noMoreNotificationsFor: class ]. > #(#SUnitGUI #SUnit) do: [ :each | (MCPackage named: each) unload ]. > > > Maybe we you should change it ? > > > > Hi folks. I was playing a bit trying to shrink a little a PharoCore image. > > My idea was to think a shrink that was be acceptable for the most common > > scenario: a runtime (production) environment where. Of course, some of the > > things I do in the shrinks has side effects, but most of the times, you can > > deal with that in such scenarios. > > Shouldn't most of the code you publish be part of the <cleanup> protocol? > > > You refere to the "new" cleanUp protocol ? > > The thing is that not everything is a cleanUp, but a shrink. Suppose the code that zap all the organizations...that's not a cleanUp. > So, maybe yes, but not all of them. > > Cheers > > Mariano > > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Tue, Mar 23, 2010 at 1:52 PM, Stéphane Ducasse <[hidden email]> wrote: mariano Thanks...I didn't know. So...instead of cleanUp: aBoolean why not to have a method called shrink ? or something better that someone can think :) Cheers Mariano
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Adrian Lienhard
On Mar 23, 2010, at 10:29 AM, Adrian Lienhard wrote: > Hi Mariano, > > Great to see further progress on this! I'll take a closer look at your script this evening. But what I wonder is why PharoCore 1.1 is so big and you only get down to 9MB (is this the size on disk?)? > > In a PharoCore 1.0 running #cleanUpForRelease, #cleanUpForProduction, deleting the class ScriptLoader and all changesets I get an image that is 8.1MB on disk. In 1.1, I get 7.6MB. -> I added cleanUpForRelease as the last call before deleting the package in cleanUpForProduction. -> I added the code code to empty the changeset after that. (I will put these fixes with Mariano's and Noury's (related to the logo) into the release today) Cleaning the changesets is *important* as they hold on to a lot of stuff... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Mar 23, 2010, at 14:53 , Marcus Denker wrote: > > On Mar 23, 2010, at 10:29 AM, Adrian Lienhard wrote: > >> Hi Mariano, >> >> Great to see further progress on this! I'll take a closer look at your script this evening. But what I wonder is why PharoCore 1.1 is so big and you only get down to 9MB (is this the size on disk?)? >> >> In a PharoCore 1.0 running #cleanUpForRelease, #cleanUpForProduction, deleting the class ScriptLoader and all changesets I get an image that is 8.1MB on disk. > > In 1.1, I get 7.6MB. > > -> I added cleanUpForRelease as the last call before deleting the package in cleanUpForProduction. > -> I added the code code to empty the changeset after that. > > (I will put these fixes with Mariano's and Noury's (related to the logo) into the release today) > > Cleaning the changesets is *important* as they hold on to a lot of stuff... Cool! We should also not forget to add and run the changeset cleaning to 1.0 before the release. Adrian > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Mariano Martinez Peck
El mar, 23-03-2010 a las 13:56 +0100, Mariano Martinez Peck escribió:
> > > On Tue, Mar 23, 2010 at 1:52 PM, Stéphane Ducasse > <[hidden email]> wrote: > mariano > > cleanUp: true > support agrresive cleanup = "shrink" > > > > > Thanks...I didn't know. So...instead of cleanUp: aBoolean why not > to have a method called shrink ? or something better that someone can > think :) Because not only shrinks the image, but also does other clean up tasks like resetting caches and similar. They have a shrink effect, but mainly are for cleaning things for example for release. > > Cheers > > Mariano > > > On Mar 23, 2010, at 10:24 AM, Mariano Martinez Peck wrote: > > > > > > > On Tue, Mar 23, 2010 at 10:19 AM, Lukas Renggli > <[hidden email]> wrote: > > What I do on my build server is to unload the tests: > > > > (MCWorkingCopy allManagers > > inject: Gofer new > > into: [ :gofer :each | > > ((each packageName endsWith: 'Test') or: > [ each > > packageName endsWith: 'Tests' ]) > > ifTrue: [ gofer package: each > packageName ]. > > gofer ]) > > unload. > > > > > > ScriptLoader >> cleanUpForProduction do that but similary: > > > > #(#Tests #CollectionsTests #CompilerTests #FreeTypeTests > #GraphicsTests #KernelTests #MorphicTests #MultilingualTests > #NetworkTests #ToolsTest) > > do: [ :each | (MCPackage named: each) unload ]. > "unload SUnit" > > Smalltalk globals > > at: #TestCase > > ifPresent: [ :class | SystemChangeNotifier > uniqueInstance noMoreNotificationsFor: class ]. > > #(#SUnitGUI #SUnit) do: [ :each | (MCPackage named: > each) unload ]. > > > > > > Maybe we you should change it ? > > > > > > > Hi folks. I was playing a bit trying to shrink a little a > PharoCore image. > > > My idea was to think a shrink that was be acceptable for > the most common > > > scenario: a runtime (production) environment where. Of > course, some of the > > > things I do in the shrinks has side effects, but most of > the times, you can > > > deal with that in such scenarios. > > > > Shouldn't most of the code you publish be part of the > <cleanup> protocol? > > > > > > You refere to the "new" cleanUp protocol ? > > > > The thing is that not everything is a cleanUp, but a shrink. > Suppose the code that zap all the organizations...that's not a > cleanUp. > > So, maybe yes, but not all of them. > > > > Cheers > > > > Mariano > > > > > > Lukas > > > > -- > > Lukas Renggli > > http://www.lukas-renggli.ch > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
2010/3/23 Miguel Enrique Cobá Martinez <[hidden email]> El mar, 23-03-2010 a las 13:56 +0100, Mariano Martinez Peck escribió: You didn't understand me. When not to call it agressiveClean instead of having a fac.. boolean and having to do aBoolean ifTrue: [ blah blag] ifFalse: [ blah blah blah] There is something I don't see ? I would have: cleanUp agressiveCleanUp where this last one, may call cleanUp too
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
El mar, 23-03-2010 a las 15:04 +0100, Mariano Martinez Peck escribió:
> > > 2010/3/23 Miguel Enrique Cobá Martinez <[hidden email]> > El mar, 23-03-2010 a las 13:56 +0100, Mariano Martinez Peck > escribió: > > > > > > On Tue, Mar 23, 2010 at 1:52 PM, Stéphane Ducasse > > <[hidden email]> wrote: > > mariano > > > > cleanUp: true > > support agrresive cleanup = "shrink" > > > > > > > > > > Thanks...I didn't know. So...instead of cleanUp: aBoolean > why not > > to have a method called shrink ? or something better that > someone can > > think :) > > > Because not only shrinks the image, but also does other clean > up tasks > like resetting caches and similar. They have a shrink effect, > but mainly > are for cleaning things for example for release. > > You didn't understand me. When not to call it agressiveClean instead > of having a fac.. boolean and having to do > aBoolean ifTrue: [ blah blag] ifFalse: [ blah blah blah] > > There is something I don't see ? I would have: > > cleanUp > > agressiveCleanUp > > where this last one, may call cleanUp too > Oh, I see. No idea, that is how Keith (I think) and Andreas proposed the change for Squeak that Stef applied to Pharo. :) Cheers > > > > > > > Cheers > > > > Mariano > > > > > > On Mar 23, 2010, at 10:24 AM, Mariano Martinez Peck > wrote: > > > > > > > > > > > On Tue, Mar 23, 2010 at 10:19 AM, Lukas Renggli > > <[hidden email]> wrote: > > > What I do on my build server is to unload the > tests: > > > > > > (MCWorkingCopy allManagers > > > inject: Gofer new > > > into: [ :gofer :each | > > > ((each packageName endsWith: > 'Test') or: > > [ each > > > packageName endsWith: 'Tests' ]) > > > ifTrue: [ gofer package: > each > > packageName ]. > > > gofer ]) > > > unload. > > > > > > > > > ScriptLoader >> cleanUpForProduction do that but > similary: > > > > > > #(#Tests #CollectionsTests #CompilerTests > #FreeTypeTests > > #GraphicsTests #KernelTests #MorphicTests > #MultilingualTests > > #NetworkTests #ToolsTest) > > > do: [ :each | (MCPackage named: each) > unload ]. > > "unload SUnit" > > > Smalltalk globals > > > at: #TestCase > > > ifPresent: [ :class | SystemChangeNotifier > > uniqueInstance noMoreNotificationsFor: class ]. > > > #(#SUnitGUI #SUnit) do: [ :each | (MCPackage > named: > > each) unload ]. > > > > > > > > > Maybe we you should change it ? > > > > > > > > > > Hi folks. I was playing a bit trying to shrink a > little a > > PharoCore image. > > > > My idea was to think a shrink that was be > acceptable for > > the most common > > > > scenario: a runtime (production) environment > where. Of > > course, some of the > > > > things I do in the shrinks has side effects, but > most of > > the times, you can > > > > deal with that in such scenarios. > > > > > > Shouldn't most of the code you publish be part of > the > > <cleanup> protocol? > > > > > > > > > You refere to the "new" cleanUp protocol ? > > > > > > The thing is that not everything is a cleanUp, but > a shrink. > > Suppose the code that zap all the > organizations...that's not a > > cleanUp. > > > So, maybe yes, but not all of them. > > > > > > Cheers > > > > > > Mariano > > > > > > > > > Lukas > > > > > > -- > > > Lukas Renggli > > > http://www.lukas-renggli.ch > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > [hidden email] > > > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > [hidden email] > > > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > -- > Miguel Cobá > http://miguel.leugim.com.mx > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Marcus Denker-4
On Mar 23, 2010, at 2:53 PM, Marcus Denker wrote: > > In 1.1, I get 7.6MB. > > -> I added cleanUpForRelease as the last call before deleting the package in cleanUpForProduction. > -> I added the code code to empty the changeset after that. > > (I will put these fixes with Mariano's and Noury's (related to the logo) into the release today) > > Cleaning the changesets is *important* as they hold on to a lot of stuff... > In 11289: ScriptLoader new cleanUpForProduction -->7.6 MB Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Mariano Martinez Peck
> You didn't understand me. When not to call it agressiveClean instead of having a fac.. boolean and having to do
discuss with luc
> aBoolean ifTrue: [ blah blag] ifFalse: [ blah blah blah] > > There is something I don't see ? I would have: > > cleanUp > > agressiveCleanUp > > where this last one, may call cleanUp too > and indeed it looks a bit over-engineered for what it does. CleanUp and cleanUp are not connected have a look at the logic. We are not bound to stick with it. If you have something better we can change without any problem. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |