On 18:45, Mon, 13 Oct, Jonas Sicking wrote:
On Mon, Oct 13, 2014 at 5:52 PM, Gregory Szorc <g...@mozilla.com> wrote: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.I'm not sure if this is what's already proposed, but technically we could repackage the files during installation. I.e. repackage them from being optimized for size to being optimized for speed. This would definitely be a non-trivial amount of work though. But might be worth it if we got a 30% faster download.
I worked through some of these options in a blog post earlier this year, albeit focused on the update sizes rather than installer sizes: http://atlee.ca/blog/posts/firefox-update-sizes.html
At one point I had patches written that added lzma support to the updater so we could compress the files in the mar file with lzma instead of bz2. We'd probably want to choose something like xz today. In any case, this impacts only the size of the update on the wire, not the size on disk.
Cheers, Chris
signature.asc
Description: Digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
