- From: Nicholas Zakas <nzakas@yahoo-inc.com>
- Date: Thu, 26 May 2011 08:56:40 -0700
I'm a little surprised that this conversation has swooped back around to performance and whether or not there's a valid use case here. In addition to standalone solutions like Steve's ControlJS and Kyle's LABjs, the Mozilla and Chrome teams were also trying to come up with solutions to enable preloading of JavaScript. What I was hoping for was a consolidation of the efforts rather than a discussion as to whether or not such efforts should continue. Moving parts of the JavaScript download/execution process doesn't allow me to control when that script will be executed, which as I mentioned in a previous email, is really the crux of the issue. Sorry for repetition, but we can already preload images and CSS and apply them to the page at an arbitrary point in time. Why wouldn't we want the same thing for JavaScript? - Nicholas -----Original Message----- From: whatwg-bounces@lists.whatwg.org [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Ian Hickson Sent: Thursday, May 26, 2011 12:43 AM To: Boris Zbarsky Cc: whatwg; James Robinson Subject: Re: [whatwg] Proposal for separating script downloads and execution On Thu, 26 May 2011, Boris Zbarsky wrote: > On 5/26/11 1:10 AM, Ian Hickson wrote: > > It's presumably a whole heck of a lot more complex than brack matching: > > > > alert('fail'); > > function test () { > > // ...megabytes of perfectly fine code... > > a b; > > } > > > > ...had better not alert anything. > > And in V8 does not, indeed. > > > What we really need though is perf data, e.g. comparing how browsers > > handle code such as: > > > > <script> > > var times = []; > > times.push(new Date()); > > </script> > > <script> > > times.push(new Date()); > > function test() { > > // ...megabytes of complicated code... > > }; > > times.push(new Date()); > > test(); > > times.push(new Date()); > > </script> > > > > What are the deltas between all the times in various browsers? > > Cute idea. You have to disentangle effects like the second script's text not > being fully downloaded yet when the first script runs, so loading from file:// > or at least from cache is good. You could probably modify the test to use a > script-inserted script instead, but I suspect that would not change things > much. > > In any case, I put up that testcase using 4 copies of the non-minified version > of JQuery 1.6.1 as the "complicated code" at > <http://web.mit.edu/bzbarsky/www/testcases/javascript/parse-vs-execute-performance-jquery-1.6.1.html>. > The first load will have that downloading issue, but subsequent loads should > be ok. Or save to a local file to avoid the network effects. > > I see numbers in ms like so for the deltas (without error bars, but all are > plus or minus 4ms or so based on eyeballing): > > Firefox Nightly: 60, 0, 17 > Chrome 12 dev: 43, 0, 160 or 19 (the last number is bimodal; this > happens from file:// too, so not > network-related). > WebKit nightly: 30, 0, 30 > Opera 11: 22, 0, 10 > IE9 (on different hardware): 32, 0, 67 This suggests (modulo the bimodal behaviour in Chrome, which I assume is a bug of some sort) that Chrome in fact does act in a way that distinguishes "parsing" (or "compiling" or whatever we want to call the side-effect free preprocessing step) from the side-effect inducing "execution" step, and the former can be significantly expensive. This supports the earlier point bz was making about how that step could be moved off the main thread and thus solve what I described as "problem A" in my earlier e-mail. (I haven't yet looked at the more recent e-mails that describe other use cases; I shall get to that in due course. Sorry for the extended delays in getting to feedback this year.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 26 May 2011 08:56:40 UTC