> Am 04.03.2015 um 14:19 schrieb [email protected]: > > On Wed, Mar 4, 2015 at 1:56 PM, Marcus Denker <[email protected] > <mailto:[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. > To be sure if you want that you have to test it. You have always take into account that a smaller file will have less I/O to read from disk. This could lead into a speed up because you spare slow disk I/O and compensate with fast memory operations. Even if there isn't a benefit you are always free to decompress the image and put it on disk. No need to use it like it was delivered.
And btw. how often do you need to spin up a server?? ;) Norbert
