On Mon, Oct 13, 2014 at 05:39:31PM -0700, Gregory Szorc 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.
IIRC there is a bug about that. Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
