W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2011

[whatwg] Proposal for separating script downloads and execution

From: Nicholas Zakas <nzakas@yahoo-inc.com>
Date: Thu, 26 May 2011 08:56:40 -0700
Message-ID: <B66541E954ECF146AD8CA69D34A283FF3AA7805297@SP2-EX07VS02.ds.corp.yahoo.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:33 UTC