Re: [Pharo-project] [Pharo-users] Minimal pharo
Hi Annick. I don't know which image they told you, but if you take a PharoCore 1.1.1 from here: http://www.pharo-project.org/pharo-download/stable-core And you evaluate: ScriptLoader new cleanUpForRelease. And then save and quite, the image is 6.8 MB. Another hack I sometimes do is o put all all classes with the default category. You can still can browse and recompile the whole image. Most production enviroments don't care about categories...they make sense when developing. (not everybody agree). But anyway, if you then evaluate: Smalltalk allClassesAndTraitsDo: [:each | each zapOrganization ]. Symbol compactSymbolTable. Smalltalk garbageCollect Then the resulted image is 6.1 mb ;) If you then evaluate: "Compact all MethodDictionary instances" | oldInstances newInstances | oldInstances := MethodDictionary allInstances. newInstances := oldInstances collect: [ :md | (MethodDictionary new: md size) compactCopyFrom: md; yourself]. oldInstances elementsForwardIdentityTo: newInstances. "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 resetCurrentToNewUnnamedChange Set. ChangeSet current initialize. ChangeSet classPool at: #AllChangeSets put: (OrderedCollection with: ChangeSet current). Symbol rehash. 3 timesRepeat: [ Smalltalk garbageCollect. Symbol compactSymbolTable ]. You will have a 5.9 MB image :) is that enought? If not, you can start unloading packages. Esteban did a lot of work with this of IPhone images. You can ask him. ps: I wonder if any of those scripts should be added to ScriptLoader Cheers Mariano On Tue, Jan 4, 2011 at 6:48 PM, Annick Fron <info@afceurope.com> wrote:
Hi all,
I have now tried the minimal images indicated by Torsten and Stephane, on Windows it amounts to 9.1 Mega in memory ... Would it be smaller on Linux ? Yet, I still need a shoe horn, having only 8 M ram from which 1.5 is already taken by the kernel... Any idea to downsize even more ? Best regards
Annick Fron
On Jan 4, 2011, at 22:42 , Mariano Martinez Peck wrote:
ps: I wonder if any of those scripts should be added to ScriptLoader
Yes, that would be good! Like this we can improve them and other people can contribute. Esteban, could you share your experience with unloading packages? I assume you had to also reorganize packages to make them cleanly unloadable? If yes these changes should be integrated to improve the modularization. Cheers, Adrian
Hi all, Yes, I agree with Adrian, all cleanings should be integrated. Perhaps in #cleanUpForProduction that already integrates some elements pointed by Mariano. #Luc 2011/1/5 Adrian Lienhard <adi@netstyle.ch>
On Jan 4, 2011, at 22:42 , Mariano Martinez Peck wrote:
ps: I wonder if any of those scripts should be added to ScriptLoader
Yes, that would be good! Like this we can improve them and other people can contribute.
Esteban, could you share your experience with unloading packages? I assume you had to also reorganize packages to make them cleanly unloadable? If yes these changes should be integrated to improve the modularization.
Cheers, Adrian
send code :) On Jan 5, 2011, at 9:16 AM, Luc Fabresse wrote:
Hi all,
Yes, I agree with Adrian, all cleanings should be integrated. Perhaps in #cleanUpForProduction that already integrates some elements pointed by Mariano.
#Luc
2011/1/5 Adrian Lienhard <adi@netstyle.ch>
On Jan 4, 2011, at 22:42 , Mariano Martinez Peck wrote:
ps: I wonder if any of those scripts should be added to ScriptLoader
Yes, that would be good! Like this we can improve them and other people can contribute.
Esteban, could you share your experience with unloading packages? I assume you had to also reorganize packages to make them cleanly unloadable? If yes these changes should be integrated to improve the modularization.
Cheers, Adrian
Hi, I don't think my experience is really usable for general image shrinking. What I was doing is preparing images to run on the iPhone, and then I was cutting a lot of things needed in any other scenarios. In fact, I named my "technic" as "brute shrinking" :P and what I was using was an adaptation of Pavel's experiments: 1) I run all the cleans provided on Pharo. 2) I change the morphic UI with a dummy one. 3) I remove lots of packages using package unloader (and I said: lots... any package I'm not using). 4) I remove lots of classes (again, any clearly not-used class remaining in not unloaded packages) 5) I remove lots of methods (using Pavel's listing, here) 6) finally I was removing even InputEventFetcher, etc. (no need for a iOS user interface, I'm processing the events in "other way") with all this, my smallest image were about 4.1M... and it was working properly inside an iPhone :) as you can see... it doesn't look like it is useful for real non-mars scenarios... I can provide the scripts, of course, if you still think it is useful. and I thought on reorganize, taking into account all this drops, yes... but the experiments were aborted by the apple clause change... now solved, but no time to continue the work on it yet :) Cheers, Esteban El 05/01/2011, a las 4:58a.m., Adrian Lienhard escribió:
On Jan 4, 2011, at 22:42 , Mariano Martinez Peck wrote:
ps: I wonder if any of those scripts should be added to ScriptLoader
Yes, that would be good! Like this we can improve them and other people can contribute.
Esteban, could you share your experience with unloading packages? I assume you had to also reorganize packages to make them cleanly unloadable? If yes these changes should be integrated to improve the modularization.
Cheers, Adrian
Ah, I forgot to say the the general idea of my "brute shrinking" was opposite to Pavel's idea: Pavel's pharo kernel images is about to have a really tiny image and use that as a foundation to build major images. Mine is: having already a production image, I want to strip from image all things I'm not using, so my *final* image (not my starting image) is as small as possible. Cheers, Esteban El 05/01/2011, a las 4:58a.m., Adrian Lienhard escribió:
On Jan 4, 2011, at 22:42 , Mariano Martinez Peck wrote:
ps: I wonder if any of those scripts should be added to ScriptLoader
Yes, that would be good! Like this we can improve them and other people can contribute.
Esteban, could you share your experience with unloading packages? I assume you had to also reorganize packages to make them cleanly unloadable? If yes these changes should be integrated to improve the modularization.
Cheers, Adrian
Hi Esteban, Yes, I know... So, how do you do the shrinking? ;) Do you unload by package? If yes, are the remaining MC packages "clean" and there are no obsolete classes etc. in the resulting image? Cheers, Adrian On Jan 5, 2011, at 13:21 , Esteban Lorenzano wrote:
Ah, I forgot to say the the general idea of my "brute shrinking" was opposite to Pavel's idea: Pavel's pharo kernel images is about to have a really tiny image and use that as a foundation to build major images. Mine is: having already a production image, I want to strip from image all things I'm not using, so my *final* image (not my starting image) is as small as possible.
Cheers, Esteban
El 05/01/2011, a las 4:58a.m., Adrian Lienhard escribió:
On Jan 4, 2011, at 22:42 , Mariano Martinez Peck wrote:
ps: I wonder if any of those scripts should be added to ScriptLoader
Yes, that would be good! Like this we can improve them and other people can contribute.
Esteban, could you share your experience with unloading packages? I assume you had to also reorganize packages to make them cleanly unloadable? If yes these changes should be integrated to improve the modularization.
Cheers, Adrian
participants (5)
-
Adrian Lienhard -
Esteban Lorenzano -
Luc Fabresse -
Mariano Martinez Peck -
Stéphane Ducasse