> On 04 Mar 2015, at 14:19, [email protected] wrote: > > On Wed, Mar 4, 2015 at 1:56 PM, Marcus Denker <[email protected]> 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
