[Pharo-project] Major shrinks
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 ].
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
On Tue, Mar 23, 2010 at 10:19 AM, Lukas Renggli <renggli@gmail.com> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <renggli@gmail.com> 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 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 Tue, Mar 23, 2010 at 1:52 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
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 :) 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 <renggli@gmail.com>
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 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <stephane.ducasse@inria.fr> 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 <renggli@gmail.com> 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 > 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
_______________________________________________ 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
-- Miguel Cobá http://miguel.leugim.com.mx
2010/3/23 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com>
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 <stephane.ducasse@inria.fr> 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
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 <renggli@gmail.com> 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 > 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
_______________________________________________ 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
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 <miguel.coba@gmail.com> 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 > <stephane.ducasse@inria.fr> 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 > <renggli@gmail.com> 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 > > 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 > > > _______________________________________________ > 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
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ 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
-- Miguel Cobá http://miguel.leugim.com.mx
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
discuss with luc 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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Tue, Mar 23, 2010 at 10:29 AM, Adrian Lienhard <adi@netstyle.ch> 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
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.
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.
yes. Ahh be aware....cleanUpForProduction in 1.1 is cool: he kill himself (unload the package ScriptLoader) at the end of the cleanUp ;)
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 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 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.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.
participants (6)
-
Adrian Lienhard -
Lukas Renggli -
Marcus Denker -
Mariano Martinez Peck -
Miguel Enrique Cobá Martinez -
Stéphane Ducasse