Le 04/03/2015 14:29, Marcus Denker a écrit :
On 04 Mar 2015, at 14:19, phil@highoctane.be <mailto:phil@highoctane.be> wrote:
On Wed, Mar 4, 2015 at 1:56 PM, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
Ok, this is now in and the image is now 22.7MB. with all examples, tests, tutorials, ConfigurationOf, Metacello...
Looks like we'll be able to start boasting about that...
It is a first step... There is still a lot of duplicated and dead code, for example. But aside from that:
We should really have a look into sharing e.g. identical large strings (using a copy-on-write proxy) and compression... e.g. Forms are compressed (see #hibernate) on shutdown. Why no do more like that, but more late bound? Most of the 22MB are not part of the working set... we could gain a lot of space by compressing once as the last state of the build.
Another thing I would like to have is to compress the distribution images and have the VM uncompress them on startup. LZ4 decompresses with 2GB/second *per core*... and the resulting image would be 12MB. This way we could have .pharo images and just use those, no need to have a zip on the build server.
Interesting but not sure I'd like to have images going through decompression everytime I spin them up. Especially if there are a lot of the in a server
As I said: it decompresses with 2GB/second. How much slower would the startup be for a 22MB image? (The idea would be to only do that for small images)
To quote https://code.google.com/p/lz4/
ââ¦. extremely fast decoder, with speed in multiple GB/s per core, typically reaching RAM speed limits on multi-core systems."
Marcus
Are you sure it's worth the added complexity of a self-decoding image in lz4 (as well as a dependency on yet one more external item)? Thierry