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

[whatwg] Proposal for separating script downloads and execution

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 10 Feb 2011 13:02:43 -0800
Message-ID: <AANLkTikMvOq+pt5Z-nuW3LNRY+JQTADzq81b99Xpt6AL@mail.gmail.com>
On Thu, Feb 10, 2011 at 12:53 PM, Kyle Simpson <getify at gmail.com> wrote:
>>> 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.

Nope, execution is the culprit here, as function declarations are
actually executed code.  Saying "function foo() { bar(); }" is the
same as saying "window.foo = function(){ bar(); };" (module a few
irrelevant details).  The act of defining functions requires executing
functions (hidden behind the syntax of an operator, but still).

Solving this does require deferring execution entirely, like the GMail
Mobile team was able to do with the comment hack.

~TJ
Received on Thursday, 10 February 2011 13:02:43 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:03 UTC