[whatwg] Proposal for separating script downloads and execution
Boris Zbarsky
bzbarsky at MIT.EDU
Thu Feb 10 12:36:46 PST 2011
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
More information about the whatwg
mailing list