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
