[whatwg] Proposal for separating script downloads and execution

On Wed, May 25, 2011 at 8:05 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> There's a big conceptual difference between parsing the script and
> executing it. ?We need to be careful not to conflate the two, even if
> browsers don't *currently* separate them.

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.  If you have a script that
does nothing but define a big function, and it takes some time to run,
it's because actually creating the objects and so on is taking the
time, not anything that can be pushed off to a background thread.  So
I stand corrected on that point.  It seems the only thing you could
easily separate is the download.  Notable lines:

# [02:19] <AryehGregor> But I assume everyone does something like
compile the whole file to bytecode first thing, at least.
# [02:19] <jamesr> no
# [02:21] <jamesr> the only thing we do on a chunk of script in v8
currently before starting to execute code is to essentially brace
match
# [02:21] <jamesr> also keep in mind that evaluating the source
"function foo() { }" is _executing_ code
# [02:21] <AryehGregor> The assertion in that thread is that
compilation of large amounts of causes visible lag if it has to be
done synchronously, even if the code doesn't actually do anything
beyond define some functions.  Is that the case in V8?
# [02:21] <jamesr> that's setting a variable 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
# [02:22] <jamesr> which you can't meaningfully pass to another thread
# [02:22] <jamesr> you can brace match on another thread, but that's
not going to buy you much
# [02:23] <jamesr> i haven't jumped in on that thread because everyone
is using slightly different terminology and it's just kind of a mess
:/
# [02:24] <jamesr> i think what authors want is a way to download
script but not execute it
# [02:32] <AryehGregor> According to you, though, use case A was incoherent.
# [02:33] <jamesr> incoherent in modern JS engines where there's not
much of a distinction between parse and execution, yes

If I understand correctly, that means all of the following key
statements are incorrect (someone please correct me if I
misunderstood):

On Mon, May 23, 2011 at 9:35 PM, Ian Hickson <ian at hixie.ch> wrote:
> The problem here seems to boil down to "we want our script-heavy page to
> load fast without blocking UI, but browsers block the UI thread while
> parsing after downloading but before executing".
>
> . . .
>
> Why? The parsing doesn't have to block loading; it can all happen in the
> background, while the page is loading.
>
> . . .
>
> Given that script execution (as opposed to the preprocessing that occurs
> before execution, including parsing and compilation) can be trivially
> fast (e.g. by making the script do nothing but expose an object) . . .
>
> . . .
>
> Given that the time the script takes to execute is already under the
> control of the author, and can be trivially short . . .
>
> . . .
>
> Problem A can't be the problem being
> solved here, since the execution takes a trivially short time compared to
> the download and compiling.

As far as I understand it now, the actual problem here is that we want
to be able to separate download and execution, not parsing and
execution.  But you can already do that by putting the whole script in
a comment, for instance, as Gmail does, so I'm not clear at this point
on why we need another feature in actual browsers.

Received on Wednesday, 25 May 2011 17:44:39 UTC