Dietrich Ayala wrote: > I keep hearing statements like "Any real app should switch to > packaged, because performance is far better".
Note that the performance difference between packaged apps and no-packaged apps might shrink due to the new work on remoting the app: protocol. Otherwise, I think people have already done a good job of explaining the performance issues. > 1) Is this true? And how much better? > > 2) Why? > > 3) What's the Web platform plan for fixing this? Is there one? I think it might be the case that packaged apps are a necessary permanent addition to the Web Platform, rather than some nasty alternative to it. A long time ago (almost two years ago) Chris Blizzard asked us whether we needed an app packaging format for performance reasons and I said "No, we can do it with TLS compression + HTTP pipelining + other networking efficiency optimizations and SPDY will help even more." But, now I think I might have been wrong. Part of that is the fact that TLS compression is no longer usable for security reasons (google "CRIME SSL Attack"). Actually, our current implementation of packaged apps is not optimal as far as download performance is concerned in two ways. First, we don't do the compression or optimization of the JAR (a.k.a. ZIP a.k.a Donovan) file in an optimal way. It turns out that the optimal way to compress and order the entries in the JAR differs for downloading vs. loading resources out of it at runtime. In particular, during downloading, we should create the JARs with 0% compression of each entry, and we should order entries so that all HTML is together, all CSS is together, all JS is together, etc. (Actually, this is an over-simplification). Then, we should use DEFLATE/Gzip content-encoding on the package. This will result in the download being much, much smaller. Then, when the client receives the JAR, it should re-compress and re-order the entries in the JAR so that each HTML/JS/CSS file is maximally DEFLATEd, and ordered according to the access patterns (launch_path first, JS and CSS for the launch_path page next, etc.). Second, we have not even tried to create an incremental package update system, that allows an app to be updated by only downloading the changed portions, instead of the whole app. Interestingly, because of the otherwise-horrendous app signing format we chose, we can actually do these transformations in the marketplace and on the client without affecting the validity of the digital signatures in the package. When these kinds of optimizations are implemented, then I think it may become very difficult for traditional request-per-resource delivery of app resources to compete against the packaged approach in terms of performance for many (most?) apps. It's also important to remember the primary motivation we had for creating packaged apps in the first place: it's much simpler for us to do the integrity enforcement (digital signatures) on these app packages than it is for us to do the same for HTTP requests (SPDY or otherwise). TLS is a good way to protect web apps, but it has limitations that signed packages overcome. So, again, I am not sure that we should be so quick to perceive app packages as an evil thing to kill. It is worth experimenting with them with an open mind, while also experimenting with alternatives. Cheers, Brian _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
