For a long time in Atom we have been wanting to have more control over startup time and, as part of this effort, back in November of last year we created an in-depth issue that illustrated where time was (and is) spent during the initialization of an Atom window. What we realized at the time was that most of the operations happening during startup were redundant and that we could use the information we had at build-time to minimize their cost.

V8 snapshots

V8 snapshots allow Electron applications to execute an arbitrary JavaScript file and output a binary file containing a heap with all the data that's left in memory after running a GC at the end of the provided script.

This suits the startup scenario described above perfectly, because we could use it to eagerly perform work when running script/build and just expose the computed data to Atom when it is opened.

The tricky part of using snapshots is that the code is executed in a bare V8 context, meaning that we have no access to Node/Electron features nor to DOM APIs and we can only run plain JavaScript code without having access to native modules either. So, in order to circumvent this issue, we decided to defer usages of forbidden APIs until runtime so that all the other computation could still happen as part of the snapshot. As a result, we set out to create a tool that automates deferring the usage such features in a way that didn't sacrifice code readability: electron-link.

electron-link

electron-link is node module that takes a JavaScript file as the entry point and a list of modules that need to be required lazily. Then, starting from the main module, it traverses the entire require graph, replacing all the forbidden requires in each file with a function that will be executed later at runtime. The output of electron-link is a file that can be passed to the mksnapshot utility to eventually generate the snapshot blob for use in Electron.

electron-link can also determine whether a module can be snapshotted or not. For instance, the following code can be snapshotted:

const path = require('path')

module.exports = function () {
  return path.join('a', 'b', 'c')
}

And the resulting code would look similar to the following snippet:

let path;
function get_path () {
  return path || path = require('path');
}

module.exports = function () {
  return get_path().join('a', 'b', 'c')
}

Conversely, when trying to transform the following code, electron-link will throw an error because it is using a forbidden module at require-time:

const path = require('path')

module.exports = path.join('a', 'b', 'c')

Improving require time

While this pull request lays the groundwork for using snapshots for all the concerns described in #13253, it only speeds up the time we were previously spending in require calls. The reason for beginning with just this one feature is that it will allow us to verify the feasibility of snapshots in production and to ship new performance improvements incrementally.

The following is a typical chart of Atom startup time:

Please, note that these benchmarks profile everything from startup till the end of packages activation. There is other stuff going on after activating packages but it depends on asynchronous I/O and the scheduling of idle callbacks, so it adds noise to the measurements.

On average it takes ~ 0.9s - 1.0s to load a stock Atom window and activate its packages when no editor is open and the tree-view is closed. A lot of it is spent in requiring modules and executing them to create classes or define objects. This is how the same chart looks like after this pull request:

You can notice how the calls to require have almost disappeared (some still need to take place for Node core modules) and how the total time has went down to ~ 0.7s - 0.8s improving startup time by ~ 15-20%.

Another scenario worth of comparison is loading an Atom window with the tree-view opened. This is how it looks like on master:

You can see it was ~ 100ms - 120ms slower and, in part, this is due to loading the package's modules. With the snapshot, on the other hand, we already paid that cost upfront during script/build and therefore the chart looks almost the same in terms of time (we still incur some overhead due to accessing the disk synchronously in the tree-view, but that's another story):

This kind of improvement should apply to all the bundled packages because they are now required during the snapshotting phase.

Caveats

Please, note that this pull request disables the asar bundle. Its introduction was mainly driven by two factors:

1. Lots of file system calls to stat the files.
2. Long path issues on Windows.

The former will be automatically addressed by snapshots because most of the fs calls will now happen during script/build, whereas the latter was solved by upgrading to npm 3 back in #11897.

Another caveat is that all the code that is snapshotted won't be inspectable in the DevTools, although stack traces should still be present and provide clear information about the call site where the error was thrown from.

Next steps

Overall, we are really excited about snapshots and we think we can further improve startup time by performing even more work during script/build. This could include eagerly constructing an AtomEnvironment, parsing grammars and snippets, loading and parsing less style sheets, etc.

Also, before merging this there are a couple of additional tasks that need to be addressed:

• Merge Enable snapshot fs-plus#37.
• Merge Enable v8 snapshot for this module node-pathwatcher#119.
• Clean up shouldExcludeModule and remove unnecessarily excluded modules.
• Use https://github.com/electron/mksnapshot to generate the snapshot.
• Copy the generated snapshot to the right location on Mac.
• Copy the generated snapshot to the right location on Windows.
• Copy the generated snapshot to the right location on Linux.
• Ensure source maps location translation in stack traces works correctly.
• Fix tests.
• Merge Upgrade fs-plus to version 3.0.0 #13940.
• Merge Stop using asar archives apm#693.
• Merge Remove atom-space-pen-views and custom elements from bundled packages #13254.
• Test drive!

/cc: @atom/maintainers