On 07/09/2013 02:45 PM, Fabrice Desre wrote:
On 07/09/2013 02:25 PM, Nicolas B. Pierron wrote:
I agree, and where I think packaged app (zip of all used files) are good
for the size of the initial download (even if they are way smaller than
Android ones) but I do not think this is good for updates. Suppose, I
have a web site with 10 pages. I want to add an extra page. I will
probably modify one existing page and add the new page into the zip
file. Why should we re-download all resources, instead of the 2
modified files?
True, and I'd like us to support differential updates, at least from
version N-1 to version N. Someone at version N-2 updating to version N
would need to do a full update.
Versionning is also an issue for large JS applications as small
modifications to the cross-compiled code (asm.js) should not cause the full
script to be downloaded again.
The problem of versionning is that you need some server instrumentation. We
were discussing this point with Luke & Brian last days, and a way to do it
would be to instrument the server to recognize and answer to some arguments
in the URL, such as:
http://example.com/foo.js?fromVersion=<md5-of-the-cached-version>
Doing it this way would benefit from the HTTP proxy caches, which might be
essential for operators when popular application such as twitter are updated.
The same versionning scheme can also work for app-cache applications:
http://example.com/foo.js?fromManifestVersion=<md5-of-the-manifest-file>
Packaged apps are smaller and faster to read, as they are contained in
one monolithic zip file. But I do not see any limitations in Gecko for
building a zip file out-of the app-cache manifest. On the contrary, we
can even do better by sorting the files in function of the order in
which they are listed in other pages or how frequently they are used.
Fwiw, we did zip reordering at some point and that was not helping with
startup time, so that didn't land.
Good to know.
In addition, if we are packing our-self the resources, we can re-pack
them with additional meta-data such as the pre-compiled code for asm.js
or the pre-parse lazy-script & bytecode for non-asm.js code.
How much would we gain from doing that?
For asm.js, this would be a huge WIN, as the compilation time might be
important
That's something I have to investigate for normal scripts. But caching at
least the lazyScripts will prevent one pass on the file, which check and
identify the functions and there bindings. Caching the bytecode might be
harder but we could prevent reading the source of all functions which are
executed during the load of the JavaScript. We hope to improve the load
time of cached/packed JS files that way.
--
Nicolas B. Pierron
_______________________________________________
dev-b2g mailing list
dev-b2g@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-b2g
