On 5/25/11 8:44 PM, Aryeh Gregor wrote:
I just discussed this on IRC with jamesr, of the Chrome team:
http://krijnhoetmer.nl/irc-logs/whatwg/20110526#l-97
According to him, the parsing and compilation time of JavaScript can't
be usefully separated from the execution.
That sounds like a V8 implementation detail. It's certainly not the
case in Spidermonkey; the bytecode compilation in spidermonkey is a
noticeable part of script execution for large scripts (because it
involves various parsing operations, not just paren matching, as well as
constant folding etc) and could in fact be done on a separate thread.
# [02:21]<jamesr> also keep in mind that evaluating the source
"function foo() { }" is _executing_ code
Actually _evaluating_ it is, yes. That has to happen on the main thread.
# [02:21]<jamesr> that's setting a variable called 'foo' on the global object
Not quite; it's defining a property called 'foo' on the global object.
# [02:22]<jamesr> i think that assertion is based on the time spent
executing the code
# [02:22]<jamesr> i.e. assigning the global variable to 'foo' and
dealing with all the side effects of that
If there is only one function in the script, there is exactly one
property definition happening. That doesn't have much in the way of
side effects.
# [02:22]<jamesr> you can brace match on another thread, but that's
not going to buy you much
In V8.
But again, if brace-matching+executing a script of the form:
function foo() {
// megabytes of code here
}
is fast in V8 already, then there is no problem to solve there to start
with, right? Is it the case that this is fast in V8?
# [02:33]<jamesr> incoherent in modern JS engines where there's not
much of a distinction between parse and execution, yes
I think this is generalizing from V8's implementation in a way that
doesn't necessarily make sense for other JS engines.
-Boris
