I looked at lzma2 a while ago for FFOS. I got pretty consistently 30% smaller omni.ja with that. We could add it pretty easily to our decompression code but it has slightly different memory behavior.
Andreas On Oct 13, 2014, at 5:39 PM, Gregory Szorc <g...@mozilla.com> wrote: > On 10/13/14 4:54 PM, Chris More wrote: >> Does anyone know or could any of you create a breakdown of the major blocks >> of the Firefox installer and each of their respective sizes or percentage of >> the whole? >> >> For example, the win32 installer for Firefox 32 is 34MB. The Firefox Growth >> team [1] like to know of that 34MB, what is the percentage or size of each >> of the components within the 34MB. As for the granularity of the breakdown, >> it would be by some logic way of breaking down Firefox. For example, >> SpiderMonkey, tools, XUL, etc. I'll leave the granularity up to you on what >> you consider a logic block to quantify together. >> >> Why am I asking this? >> >> The win32 Firefox full installer continues to grow (see attachment) each >> release and it has been on an increasing growth since Firefox 29. Like >> anything on the web, the time it takes to download something (webpage, >> binary file, etc.) affects the key conversion rate by some amount. The >> Firefox Growth team has a project to understand what features/changes in >> Firefox are contributing to the growth or size of the installer. We've asked >> a few times previously, but it doesn't look like the documentation or >> analysis exist. >> >> Would anyone be able to take on this project as it would be very helpful to >> the team? I am imagining a pie chart of the the current installer and then a >> table of the name of each component, their size (KB or MB), and any >> additional meta data. > > 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 if this has been considered or attempted before. Things are > slightly complicated by the fact that omni.ja is a slightly customized zip > format. We'd need to ship code to encode omni.ja. > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
