Firefox Performance: The “don’t touch the damn disk” edition.

I mentioned in previous blog posts that the clearest message that has come out of the Firefox startup performance research is that most of the time starting the application is spent loading and reading files from disk. On some platforms, file IO is far more expensive than others – this hurts startup time especially bad on Mac, and on mobile devices. This post highlights some work that Taras Glek has done to reduce file IO in Firefox (and other Mozilla applications) by improving the way we package collections of files and directories into JAR files.

First, he resurrected an older idea, modifying our JAR file reader to map the contents of JAR files into memory using mmap. He then combined a bunch of smaller JAR files into two bigger files: browser.jar and toolkit.jar. These changes provide a few benefits:

  • Our reader was stat’ing the JAR file each time that it read something from inside. The mmap change reduces the system calls necessary to read all the smaller files from inside our JAR files.
  • Fewer JAR files means files are fewer places on disk, and the initial JAR finding, opening and reading system calls happen fewer times.
  • By combining files inside a large JAR, they’re placed contiguously on disk, allowing the smaller files inside of the JARs to be found and read much quicker.

The effects of these changes were significant. The landing of the JAR-combining change resulted in some fabulous graphs, shown below, along with comments to highlight the good bits.

Tp3 Graphs

Tp3 Graphs

Tp3 is a page loading test – it cycles through 400 pages from the Alexa Top 500 list from 2006, measuring how long it takes to open each page. As you can see on the graph, the time it took to complete the test went down by about 6.5% on Leopard, 9% on Linux, 2.5% on Tiger, 11% on Windows XP, and a clear downward trend on Vista, where the noise level is a bit too high to get a number.

Tp4 Graphs

Tp4 Graphs

Tp4 is the successor to Tp3, and cycles through 100 of the Alexa Top 500, from 2009. The time to run the test improved by 3.5% on Leopard, 7.8% on Linux, 2.5% on Tiger, 6% on Windows XP, and again Vista clearly improved, but the noise level is too high to easily figure out by how much.

Ts Graphs

Ts Graphs

Ts is a basic browser startup test – it measures the average time to start the browser up. There’s no clear startup win visible here, except perhaps on Vista. There’s maybe even a slight loss on Mac. However, if you look closer, you’ll notice that the graphs for Linux and Vista and Windows XP are all much less *noisy*! The absolute wall clock time did not decrease, but the variation in startup time decreased significantly on those platforms. An upside to this is that true performance improvements and regressions on those platforms will be easier to spot.

Txul Graphs

Txul Graphs

The same effect is seen in the tests measuring how long it takes to open a new XUL window. There’s maybe a slight improvement on Windows, and a regression on Tiger, but the level of noise on every platform has decreased, some down near zero variation between runs.

The improvement in page-load time from Taras’ changes is quite clear. There’s work in progress to make the JAR IO even more efficient, as well as putting additional directories of small files into the JAR files. You can follow progress and get even more details on Taras’ blog.

7 Comments on “Firefox Performance: The “don’t touch the damn disk” edition.”

  1. […] Firefox Performance: The “don’t touch the damn disk” edition. &la… […]

  2. Nickolay says:

    Weren’t these changes supposed to improve Ts, not so much Tp? Even bug 468011#c0 reports Ts improvements.

    Is there any explanation for the results you see? I didn’t find any in bugzilla. Just curious…

    • The Tp improvements are due to a >50% increase in JAR IO performance from the mmap changes.

      Re Ts: These changes affect cold startup moreso than warm startup – and Ts throws away the worst run of the 10 before calculating it’s final score. We have a cold-startup Ts in progress now, which should better reflect changes like this.

      • Nickolay says:

        Ah, right. I should have remembered that Ts measures warm startup. Thanks for the clarification!

  3. […] Follow this link: Firefox Performance: The “don't touch the damn disk” edition … […]

  4. […] Taras Glek stepped up and made major improvements to the performance of libjar, we couldn’t resist making him the module owner. libjar hasn’t had an official owner […]

  5. shaver says:

    That’s a great advance, and will definitely move the cold-Ts numbers in the right direction. I have long held the theory that our “jitter” in Ts was mostly due to the amount of I/O we do, which makes us sensitive to changes in how the filesystems are physically laid out. That can change over time on a given system, and definitely between systems that are “identical” in terms of filesystem-visible layout.

    That it affects Tp at all, though, points at another fruitful line of inquiry: why the holy heck are we doing JAR accesses at *all* during Tp? 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s