W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2011

[whatwg] Proposal for separating script downloads and execution

From: Glenn Maynard <glenn@zewt.org>
Date: Wed, 25 May 2011 14:47:37 -0400
Message-ID: <BANLkTikUrKiU8fRpgXEcknesKQSctJRxfQ@mail.gmail.com>
2011/5/25 Nicholas Zakas <nzakas at yahoo-inc.com>:
> I already explained that in my previous email. Parsing and compilation on
a background thread removes some of the problem but not all of it.
Ultimately, even if the script is just a function waiting to be called, the
browser still executes it in a blocking fashion after parsing and
compilation. It's the execution that is troublesome part because it
interferes with the UI. The fact that the script isn't doing much is
helpful, but once again, there will be a non-zero interrupt that can affect
user experience.

The recommendation that your script look something like this:

var yourAPI = function() { throw "API has not been initialized; initAPI must
be called"; };
var initAPI = function() {
   initAPI = function() { };
   yourAPI = function() {}
   yourAPI.prototype.func = function() { }
   [...];
   return yourAPI;
}

and "..." is lots of code.

There are three steps to loading this API: parsing it, executing the
top-level function and calling initAPI().

The assertion is that it should be possible for top-level execution to take
near-zero time, regardless of the length of "[...]".  This seems reasonable
to me.  I don't know the internals of various Javascript engines, but
looking at it in Python terms, all the top-level does is create two function
objects from two code objects, where code objects represent the parsed code,
and function objects represent the live function with its global scope and
upvalues (closure variables) attached.  All of the actual work happens when
initAPI is called, and you can choose when to do that.

I put a simple test here:
https://zewt.org/~glenn/test-top-level-context-execution.  The top-level
function takes no measurable time for me in FF4 and Chrome 11.

(That assumes there's no CPU time tied to execution--work that can't be done
asynchronously--which happens before the first line of code where this code
starts measuring time.  Someone familiar with engine internals would need to
comment if that's the case.)

It's been a while since our earlier discussion and I havn't yet entirely
refreshed myself on it, so I'm not sure if this fully covers what we
discussed, but it seems like a reasonable approach.

-- 
Glenn Maynard
Received on Wednesday, 25 May 2011 11:47:37 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:33 UTC