In my last post, I explained what Syzygy was and discussed some preliminary results from using it with Firefox. I finally have results of running the whole Syzygy toolchain (instrumentation/profiling/reordering) and some numbers to share.
First off, I mentioned that I could get the call tracing to work right. That was because I hadn’t installed Syzygy’s counterpart, the Sawbuck log viewer. That’s the bit that contains the trace provider for the call tracer; you can download Sawbuck or you can install the src/sawbuck/Debug/sawbuck.msi module from your own build.
Secondly, these numbers need to be collected with a change to browser/app/nsBrowserApp.cpp to turn preloading off; otherwise the preloading of xul.dll will defeat the tracing mechanism. With an eye to eventually getting this into the Mozilla build process, I’m not sure how well that bit will work out; perhaps preloading could be made dependent on an environment variable. We can then turn off preloading during the build + postlink and get the benefits of a properly laid-out xul.dll without hacks in the source.
With my laptop (Windows 7, Intel SSD), a cold startup of a trunk build of Firefox results in about 2300 hard page faults and 43000 soft page faults. These terms are what Windows uses; other operating systems call them major and minor page faults, respectively. In any event, hard page faults are what we care about, because those result in talking to the hard drive.
After running the optimize program that comes with Syzygy–which automates the running of the instrumenter, the collection of profile data from the application, and reordering the library(s) in question–cold startup results in about 1400 hard page faults and 27000 soft page faults. Like the Chrome folks saw, this is about a 40% reduction in hard page faults; soft page faults in this scenario are reduced to about what you’d see with warm startup.