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
