Another example, if the omni.jar is not compressed the installer can compress it about as well as if they were individual files and the minimal compression currently used by omni.jar makes it so the installer is not able to compress the omni.jar nearly as well which increases the installer size.
Robert ----- Original Message ----- > From: "Gregory Szorc" <[email protected]> > To: "Neil" <[email protected]>, [email protected] > Sent: Tuesday, October 14, 2014 5:31:54 PM > Subject: Re: Breakdown of Firefox full installer > > On 10/14/14 5:12 PM, Neil wrote: > > Gregory Szorc wrote: > > > >> If you are looking for ideas on how to reduce download size, the way > >> omni.ja is included in the installer could be reduced by 4+ MB. Both > >> omni.ja and browser/omni.ja are zip archives, where each file has a > >> separate compression context. If you treat all files from those two > >> archives as a single compression context (like tar+bz2) and stuff them > >> in a single archive, you get size reductions of 4+ MB due to the > >> compression engine sharing state between files. We can't install > >> omni.ja like this on client systems because it is bad for performance > >> (we want the ability to extract individual files without reading a > >> large compression context - this is a benefit of the zip format). But > >> we could ship the files optimized for size (or have installer's > >> compression handle the files individually) and have the installer > >> re-encode them to omni.ja so they are optimized for performance. > > > > I'm not sure what you're trying to say here. As far as I can see what > > you're suggesting is using some RAR-like rather than ZIP-like format for > > the installer. Why would the way you're compressing the two omni.ja > > files into the installer affect the installed omni.ja files? > > The more data you throw into the compression engine, the greater the > chances there will be redundant data and you won't have duplicate > representations of that data inside the compressed result. There's a lot > of data inside both omni.ja and it turns out that many forms of > compression will find those duplicate patterns and prevent the redundancy. > > Also, we're not talking about changing omni.ja as it exists in the > installed application: only how data within omni.ja is "packaged" and > shipped in the installer. Discussions on whether omni.ja should be e.g. > lzma or laid out differently on disk are orthogonal but still important > to have (because they impact performance, especially start times). > _______________________________________________ > dev-platform mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
