On Thu, Feb 27, 2014 at 07:33:39PM +0900, Mike Hommey wrote: > On Thu, Feb 27, 2014 at 01:30:58AM +0100, Andreas Gal wrote: > > > > Could we compress major parts of omni.ja en block? We could for > > example stick all JS we load at startup into a zip with zero > > compression and then compress that into an outer zip. I think we > > already support nested containers like that. Assuming your math is > > correct even without adding LZMA2 just sticking with zip we should get > > better compression and likely better load times. Wdyt? > > I doubt this would benefit much, considering the limited window size of > the deflate algorithm.
That's actually easily verified by recreating a zip with no decompression and gzipping it... the result is 7568209 bytes if you do that for the entire omni.ja. On Thu, Feb 27, 2014 at 12:52:44PM +0000, Neil wrote: > You could compress the whole of omni.ja en bloc and stick the > startup cache at the beginning so that you don't have to completely > decompress omni.jar until such time as you use the last entry, if at > all. Note we do order omni.ja following how it's used, but that's only done on PGO builds. That said, the problem with this is that either you keep every file you ever extracted in memory (or in a disk cache), or you risk to have to decompress the archive from the beginning again when you need to read something you don't have in memory again. Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
