[whatwg] Proposal for separating script downloads and execution

[Boris Zbarsky]

On 5/25/11 8:44 PM, Aryeh Gregor wrote:
> I just discussed this on IRC with jamesr, of the Chrome team:
>
> http://krijnhoetmer.nl/irc-logs/whatwg/20110526#l-97
>
> According to him, the parsing and compilation time of JavaScript can't
> be usefully separated from the execution.

That sounds like a V8 implementation detail.  It's certainly not the 
case in Spidermonkey; the bytecode compilation in spidermonkey is a 
noticeable part of script execution for large scripts (because it 
involves various parsing operations, not just paren matching, as well as 
constant folding etc) and could in fact be done on a separate thread.

> # [02:21]<jamesr>  also keep in mind that evaluating the source
> "function foo() { }" is _executing_ code

Actually _evaluating_ it is, yes.  That has to happen on the main thread.

> # [02:21]<jamesr>  that's setting a variable called 'foo' on the global object

Not quite; it's defining a property called 'foo' on the global object.

> # [02:22]<jamesr>  i think that assertion is based on the time spent
> executing the code
> # [02:22]<jamesr>  i.e. assigning the global variable to 'foo' and
> dealing with all the side effects of that

If there is only one function in the script, there is exactly one 
property definition happening.  That doesn't have much in the way of 
side effects.

> # [02:22]<jamesr>  you can brace match on another thread, but that's
> not going to buy you much

In V8.

But again, if brace-matching+executing a script of the form:

  function foo() {
    // megabytes of code here
  }

is fast in V8 already, then there is no problem to solve there to start 
with, right?  Is it the case that this is fast in V8?

> # [02:33]<jamesr>  incoherent in modern JS engines where there's not
> much of a distinction between parse and execution, yes

I think this is generalizing from V8's implementation in a way that 
doesn't necessarily make sense for other JS engines.

-Boris