[whatwg] Proposal for separating script downloads and execution

[Kyle Simpson]

>>For the purposes of this discussion, we are combining (but safely so, I
>>believe) "execution" and "parsing", and saying that we want to be able to
>>defer the "parse/execution" phase of script loading. 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.
>
> There are multiple phases between receiving bytes on the wire and having
> executed the code they represent. Parsing would seem unlikely to be the
> main problem here (parsing is mainly checking for syntax errors while or
> after removing the character encoding from the bytes received),

The Gmail mobile team did extensive research into this area and concluded 
that it was in fact the parsing that was the big slow-down in their case. 
>From what I recall, they have a big file with nothing but function 
declarations in it (NO EXECUTIONS), and that file took a few seconds to 
"execute" (not actually execute any functions, but parse and declare those 
functions into the global space). On the other hand, if they wrapped all the 
code in /* .. */ comments, and had that single big comment "parsed/executed" 
by the engine, it went orders of magnitude faster (unsurprisingly).

So, it strongly suggests that the parsing/interpretation of the code was in 
fact the culprit. There's nothing they could have really done to prevent 
less execution, since they weren't executing anything. It was merely the 
sheer number of function declarations being parsed and added to the 
environment that slowed everything down.

There's already in thread sufficient confusion over what "execute" means. In 
the literal sense as far as the JavaScript engine is concerned, we probably 
ARE talking about wanting to defer when the code itself (the function 
declarations) is "executed". But we need to differentiate *that* "execution" 
(which is the problem) from later "execution" (which isn't the problem) with 
actual function call invocations. For the sake of this discussion here, I've 
been referring to the first "execution" as "parsing" and the second 
"execution" as "execution".

I don't want us to derail this thread AGAIN with semantics arguments about 
what is and is not "parsing" or "execution", and whether the problem is 
"parsing" or "interpretation", or whatever you want to call that first pass 
where JavaScript code is run through the engine, even if no function calls 
were happening.

The real point is, THAT part (whatever it's called) is clearly what is so 
slow, and THAT part is what we're seeking to have control to defer. And THAT 
part won't benefit at all from telling a developer "just redesign your 
code".


> Anyway, I don't really see the problem with rewriting your code so you
> have more control over when execution takes place,

Again, this is exactly the line of degenerative conversation that I was 
trying to preempt from happening. You're assuming (wrongly) that the code is 
unnecessarily "executing" function calls at the time of inclusion, when in 
reality it's not, and so that's not the problem.

It's not a question of if I can change code from automatically invoking a 
function to controlling that function call myself. It's a question of if I 
have any way to defer when the browser interprets a huge chunk of function 
declarations present in my source code. And the answer is, currently, I 
can't defer that step, whatever we call that step.


--Kyle