Le 04/03/2015 14:29, Marcus Denker a écrit :
On 04 Mar 2015, at 14:19, [email protected]
<mailto:[email protected]> wrote:
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
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
