[whatwg] Proposal for separating script downloads and execution

[Boris Zbarsky]

On 2/8/11 3:56 PM, Kyle Simpson wrote:
> Yes, it's important to note that it's not even the *execution* of
> JavaScript code that's actually the particular issue, but rather just
> the parsing of it (even if invoking of the functionality is deferred
> until later) that causes the biggest slowdown, in most cases.

Here's the thing.  Parsing is a black-box behavior.  Nothing says a 
browser needs to do it right before execution, that it needs to happen 
on the main thread, or that it's happening at all.

For example, for Gecko we have had proposals to parse off the main 
thread, as well as to store parsed script data structures in the cache 
so on a cache hit we just load the already-parsed data.  We've also had 
proposals to parse eagerly when priming the speculative load cache; this 
could be a good bit before the script executes, assuming it ever executes.

So is control over parsing really just working around quality of 
implementation issues?  Or do you really need to constrain the timing of 
the parse so as to preclude it being done on a background thread, while 
the parser is waiting for a previous script to load?

> For the purposes of this discussion, we are combining (but safely so, I
> believe) "execution" and "parsing"

See, I'm not sure that combination is safe.

> The reason it's necessary to draw the distinction (and point out that parsing is the
> costly bit) is to defuse the argument that the script author can simply
> change the script to not execute itself until manually invoked at a
> later time.

Yes, but parsing is also the unobservable bit, which a browser therefore 
is at liberty to optimize in various ways, even if none do so far.

-Boris