On 10/13/14 5:42 PM, Andreas Gal wrote:
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.
This was discussed in the "Including Adobe CMaps" thread
(https://groups.google.com/d/msg/mozilla.dev.platform/SOInehcZa2g/ezcQRH7k_moJ).
tl;dr is we need per-file compression on client for performance reasons:
whole archive compression for actual Gecko load is a non-starter.
I see now that glandium mentioned adding functionality to the installer
in that thread. I guess it was never acted upon.
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
