On top of what Nathan explained, there was a very pragmatic reason: we
already had all the code needed to access zip files efficiently because
this is what we also use for the jar: protocol.
Fabrice
On 09/29/2015 06:28 AM, Nathan Froyd wrote:
> On Tue, Sep 29, 2015 at 8:23 AM, <[email protected]
> <mailto:[email protected]>> wrote:
>
> As we all know fxos apps are compressed and packed in zip format.
> My question is why zip format was chosen when we have a better
> compressing format tar.xz ? tar.xz has highest compression ratio
> than zip & other existing one's. even Linux kernel is distributed in
> this format due to its efficient compression. My opinion is that
> user can save some extra bandwidth when downloading apps are packed
> & distributed in tar.xz & for developers, compressing &
> decompressing tools are available for windows (7zip), Mac & linux
> also. So there is no problem.
>
>
> [disclaimer: I wasn't involved in the decision-making process, but the
> below is what I think might have been part of the discussion]
>
> It's not just about the compression ratio: you also have to think about
> resource consumption (time and memory) when decompressing. A quick
> Google search suggests that xz is somewhat slower and more resource
> hungry than the compression algorithm used in zip. And that would
> negatively affect app startup time and performance.
>
> An app also may not require all of its files at once: starting up the
> app may only require a single HTML page plus a few JavaScript files and
> maybe some images. Another part of the app may require a slightly
> different (but still small) subset). So your compression format should
> be able to support finding arbitrary files quickly. The zip format is
> ideal for this, since it has a directory-like listing of all the files
> contained in the archive. The tar format has no such index (the files
> are stored one after another with a small header prior to each file's
> data describing the name of the file, size, etc.), so finding an
> arbitrary file is quite expensive: you have to uncompress part or all of
> the .tar.xz to find each file. You could cache some of the uncompressed
> data, but it's not clear that would be effective.
>
> You could, of course, imagine some "xip" format that is like .tar.xz,
> but with a zip-like directory attached to the front so you can find
> arbitrary files quickly. But you then have to weigh the engineering
> effort involved in creating that, testing it, etc. You also have to
> consider whether xz is a good compression algorithm in this context:
> resource usage, as detailed above, compression ratios on small files
> (since you're probably not compressing the entire archive at one, but
> smaller chunks, even at the level of individual files), etc. Once all
> those factors are thrown into the mix, zip starts to look like a
> reasonable choice.
>
> -Nathan
>
>
> _______________________________________________
> dev-fxos mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-fxos
>
--
Fabrice Desré
b2g team
Mozilla Corporation
_______________________________________________
dev-fxos mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-fxos
