Platform/AreWeFunYet: Difference between revisions

Platform/AreWeFunYet (view source)

Revision as of 15:20, 14 February 2012

166 bytes added , 14 February 2012

→‎Speed of first-run

Dmandelin

313

edits

@@ Line 52: / Line 52: @@
 === Speed of first-run ===
-Game developers are concerned about the time taken to compile large JavaScript codebases. What can we do to either make JS compilation faster, or avoid compilation work? Some ideas they mentioned:
+Game developers are concerned about the time taken to compile large JavaScript codebases. Note that there are two separate compilation stages: bytecode compilation (JS->bytecode), and native compilation (bytecode->native). Currently SpiderMonkey compiles all bytecode immediately when it is loaded by a page, but functions are native-compiled only after they have run a few times (or for a few loop iterations).
-* Would adding more typing to the language make it faster to compile?
-* Could we avoid compiling all of a large codebase before starting running it?
-Adding types to language is a possibility, but isn't something that will happen soon. Possibly in the order of years out.
+We need data to show which compilation(s) are a problem.
-We can improve first-run speed by incrementally compiling as we download though.
+If it's bytecode, one solution is to compile the code as it is downloaded (bug on file?). Another is to parse only enough to get early errors, but not actually compile, making the front-end faster.
-When we cache scripts in app-cache, we could cache something other than the source, which would be faster to load again.
+Native compilation is difficult to make faster: there aren't necessarily any quick fixes.
+Ahead-of-time compilation or caching compiled code would address both issues.
 === Management of large JavaScript codebases ===