For the last couple days I've been investigating reports that N1 (a mail client based on the Atom source) launches /really/ slowly on machines with traditional spinning drives.

The ASAR archive format improves launch performance by reducing the number of file descriptors the app needs to open, but is still sub-optimal for users without SSDs. Files required to open and initialize the first window are scattered everywhere within the archive, and reads span the entire 80MB ASAR file. This is bad for a number of reasons:

• Modern hard drives take 9-12msec to seek to new read locations (SSDs take <0.16ms). In a worst case scenario where each file is in a separate, cold disk block within the ASAR file, Electron can only read 125 files a second.
• Hard drives read in blocks of either 512 bytes or 4kb (Advanced Format adopted in 2011) and many of the files in the ASAR archive are smaller than 4kb. Reading from random locations where adjacent files are not needed causes data to be loaded into cache which is not used.

Here's a graph of reads within app.asar when N1 launches. I expect this very closely mirrors Atom's read pattern at launch. The vertical axis is byte offset within the ASAR, and the horizontal axis is the order in which the file was read.

I patched Electron to log ASAR reads and their offsets to a file (PR: electron/electron#3902), and patched the ASAR library to accept this file as an "ordering hint" during the archive process (PR: electron/asar#52). This hint file allows the archive to be laid out optimally, resulting in the following read pattern at launch:

This ordering change improves launch performance considerably. I only have access to solid state drives, but I conducted tests with an old USB thumb drive. (It doesn't suffer from slow seek times, but does have a low throughput rate and #2 above applies.) For each test, I reset Mac OS X's filesystem cache (sudo purge), launched the app, and measured "time to inbox" (a standard metric we use internally).

Launching N1 from the thumbdrive is 9% faster using the optimized ASAR ordering, and I expect gains could be greater on actual HDDs.

There are a bunch of other improvements that could be made. Breaking app.asar into two archives and loading one completely into memory at launch could eliminate seeking at the cost of RAM. Memory-mapping the ASAR file might also improve performance, since it can enable other operating system optimizations. That said, these are optimizations that only impact HDD performance and may not be worth building or maintaining. Order hinting is easy to implement and maintain and I think it'd be good to add to the Atom build process.