Hi, I made a very simple experiment, with a MCLazyVersionInfo, which holds its ancestors and stepChildren in WeakArray(s), and loads it from repositories on demand. Installing it on Pharo 40511, and then flushing the Monticello package cache, reduces the image by around 5 MB: Before: memory 48,583,272 bytes old 40,721,508 bytes (83.80000000000001%) young 1,445,212 bytes (3.0%) used 42,166,720 bytes (86.80000000000001%) free 6,416,552 bytes (13.200000000000001%) After: memory 42,482,984 bytes old 35,484,236 bytes (83.5%) young 1,434,832 bytes (3.4000000000000004%) used 36,919,068 bytes (86.9%) free 5,563,916 bytes (13.100000000000001%) You can browse the history of any package and it will be reloaded on the fly :) But, but, but. When opening a repository inspector, MC will walk through all ancestors of all packages... reloading everything. Arrrg ! So I won't tell you where it is available, yet :( Thierry Le 20/02/2015 15:41, Marcus Denker a écrit :
Hi,
The current Pharo4 contains *a lot* of MCVersionInfo instances.
MCVersionInfo allInstances size
11095
The hold on to strings, Date, UUID⦠a lot of stuff. All in all, this is around 10% of the current image.
If you do
MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ].
you image is a couple of MB smaller.
In the past, when this information started to be >8MB, we did that. With the bad effect that we can not merge anymore across this boundary: we kill the past.
Now this information is of course continained in the last MCZ file, too (all of them contain the complete historyâ¦)
So would the following work?
-> we set the âancestorsâ of MCVersionInfo to #reload -> the accessor, when it sees #reload, takes the name, deduces from that the package, and goes to the repo to load the ancestry info from the MCZFile.
This means that e.g when saving a MCZFile, it would first re-create history info and then save it completely (like now), yet someone who just uses the system would never need to have this info in the image.
Marcus