[whatwg] Proposal for separating script downloads and execution

On 2/10/11 3:23 PM, Bjoern Hoehrmann wrote:
> 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)

And constructing whatever output model (AST, bytecode, whatever) your 
parser produces.

> while it is quite likely that browsers don't have very fast parsers, without very
> good benchmarks I would rather suspect the problem is more in finding
> out about the side effects of the code and eagerly pre-processing code
> like turning it into machine code

Browsers don't do much stuff eagerly in this space.

Based on my profiles of script loading and execution in Spidermonkey, 
parsing _is_ in fact pretty expensive (very commonly much more expensive 
than the initial execution for large scripts, since most of the script 
is cold).

That said, Spidermonkey's parser does in fact do some optimization 
(constant-folding and the like).  But it also ends up having to create 
large data structures, read a bunch of data, sometimes ends up running 
O(N^2) algorithms, etc, etc.

If you have actual data, not just conjecture, as to the amount of time 
the parser takes in other ECMAScript implementations, which I have not 
profiled, I would love to see that data.

> Anyway, I don't really see the problem with rewriting your code so you
> have more control over when execution takes place, for instance, you can
> just do `function load() { eval("...") }` and similar mechanisms.

Because that makes your code much slower in some cases?

-Boris

Received on Thursday, 10 February 2011 12:36:46 UTC