The template compartment should improve Shumway start-up time after the compartment is first compiled.

This bug is pretty vague. What is a template compartment? How does this relate to bug 1101386?

(In reply to Brian Hackett (:bhackett) from comment #1) > This bug is pretty vague. What is a template compartment? How does this > relate to bug 1101386? This is about an idea I outlined at the work week. For Shumway, we care about startup performance a lot, so whatever we can do to improve that we're looking into. So yes, bug 1101386 is related to this, but is a different take on the same problem. Roughly, the idea here is to generalize the self-hosting approach: we compile Shumway into a special compartment once when it's first needed. That compartment then gets frozen. To actually use the compiled code, we introduce a new function `newGlobalFromTemplate` (which might get a better name in due time). When called, `newGlobalFromTemplate` creates a new global but skips normal initialization of builtins. Instead, it does a deep copy of everything in the template global, closed-over state and all. Functions would be lazily cloned, with a slightly different mechanism from self-hosting: instead of a name, we'd store a (probably indirect, because moving GC) pointer to the source function. Perhaps we could change to that for self-hosting, too. By my estimate, this should be extremely fast and essentially unbeatable by whatever we do in terms of optimizations for all content. It does have the downside of not helping other content, of course :/ It might be something we could use for other cases, too, though, such as new tabs or the content script compartments that get created to the side of all windows for addons.

(In reply to Till Schneidereit [:till] from comment #2) > When called, `newGlobalFromTemplate` creates a new global but skips normal > initialization of builtins. Instead, it does a deep copy of everything in > the template global, closed-over state and all. Functions would be lazily > cloned, with a slightly different mechanism from self-hosting: instead of a > name, we'd store a (probably indirect, because moving GC) pointer to the > source function. Perhaps we could change to that for self-hosting, too. OK, thanks. What is in this template global, besides functions? If bug 1101386 got things down so that compiling a global script which has already been compiled elsewhere is basically just a similar clone of the results of that earlier compilation, would that approach still incur a lot of additional overhead? When loading shumway, how much of the time taken is loading/compiling code vs. executing code?

(In reply to Brian Hackett (:bhackett) from comment #3) > OK, thanks. What is in this template global, besides functions? There are two parts to this: one is that, since Shumway is TypeScript-based, the code consists of a lot of rather large chunks of nested IIFEs. All of these have to be parsed and executed during startup to finish the first phase of startup. In Shumway's case, a lot more happens in an additional phase of startup: in that phase, Shumway loads a binary file containing some AS3 class definitions and uses that to initialize Flash's standard library. It also installs quite a few functions on Object.prototype to implement AS3's MOP. Finally, and by far most messy, we change the __proto__ of quite a few constructors. This is extremely unfortunate and we're trying to find ways not to do that. It's slightly less terrible than it sounds because these constructors don't flow through all that many callsites and the instances have a stable prototype chain. It's still pretty terrible, though. As far as I can tell, the issues associated with that should essentially go away if we clone over the end result of all of this to globals where these objects are actually used. > If bug 1101386 got things down so that compiling a global script which has already > been compiled elsewhere is basically just a similar clone of the results of > that earlier compilation, would that approach still incur a lot of > additional overhead? That'd be a pretty amazing result indeed, and if that's attainable at all, we should absolutely strive for it because of the effect it'd have on startup time for sites that contain lots of similar iframes - think facebook like buttons and their ilk. For Shumway, it'd only help with phase 1 of the startup process as outlined above, though. However, there is another potentially viable way to get the whole improvement: we might be able to do phase 2 as a compilation step and bundle the resulting code in the Shumway extension. At the very least, though, that'd be much more work than what is proposed here. > When loading shumway, how much of the time taken is > loading/compiling code vs. executing code? It's hard to draw a strict line here, because syntax parsing means that parsing and execution are intertwined. Roughly, though, I'd say that parsing takes about 1/3rd of the time: when using `parse(snarf('[path to bundled shumway source]'))`, that takes about 72ms on my machine. The same with `syntaxParse` takes about 52ms. Using `eval` to also execute the source takes about 184ms. Note that this is only for phase 1 of our startup as described above: at this point we could start phase 2.

I would still love to do this, but it's far from trivial, and not needed for our initial release.

We won't implement this anymore. I think it's worth pursuing something like this for new window globals, but for Shumway it's not needed.