[whatwg] Proposal for separating script downloads and execution

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'