Rude Surprise: Startup Overhead of Windows Font APIs

Imagine a typical Firefox user who starts their Windows computer in order to surf the web. First app they launch is Firefox 4. Turned out that on systems that support hardware-acceleration for 2D graphics, Firefox 4 takes minutes to startup. WTF? XPerf-aided investigation showed that, the Windows font enumeration code causes us to do 30x more disk IO (~300MB) than the rest of Firefox code.

In order to hardware accelerate Firefox, we switched from GDI to using DirectWrite for font stuffs. Apparently, DirectWrite is a wonderful api, but the implementation has some teething issues. DirectWrite opens a connection to the Font Service (and starts it if it isn’t already running), however if service fails to respond DirectWrite proceeds to enumerate all of the system fonts on the client-side. This isn’t cool for multiple reasons: a) it is slow as hell b) it causes Firefox to run out of memory(installing IE9 helps!) sooner.  This means that currently Firefox 4 starts up a lot slower than 3.6. John Daggett is busy working on a workaround by using older GDI APIs to enumerate fonts. Firefox is one of the first popular Windows applications to switch to DirectWrite, so we get to suffer the consequences.

Unfortunately it turns out that using Microsoft GDI APIs to enumerate fonts still causes a significant amount of disk IO (~30-60MB), John plans to fix that next.

How Did We Miss This?

This bug came from a fundamental difference of how developers and users start Firefox. A developer will restart Firefox a dozen times an hour. This means we rarely get to observe true cold startup. Our tests only measure warm startup (because most operating systems make it difficult to test cold startup). Windows is also incredibly slow to develop on, so a lot of us test in a virtual machine to speed things up and avoid rebooting the computer all the time. This also makes observing cold startup hard. Fortunately xperf makes IO much easier to observe. We should deploy xperf on our test infrastructure as soon as possible.

6 comments

  1. Does IE9 have the same problem?

  2. A possible workaround would be to set the Windows FontCache service to ‘automatic’ instead of the current ‘manual’. Then ithe service will be loaded when the OS starts up, instead of the first time an application needs it. And yes … it will cause your computer to boot up slower.

    Interestingly, running IE9 (or any other application that uses DirectWrite) before you start up Firefox, will also cause the FontCache to be loaded in memory, as IE9 will take the hit.

    More info in https://bugzilla.mozilla.org/show_bug.cgi?id=602792 Comment 61 is the best explanation.

  3. Installing KB2028560 update seems to fix some of the DirectWrite issues as mentioned in one of the bugzilla bugs. Too bad the DirectWrite API and Win7 is still very buggy, requiring more bugfixes.

    http://support.microsoft.com/kb/2028560

    32bit
    http://download.microsoft.com/download/9/7/6/976634BE-DC4D-4B7B-9567-209811D7AF14/Windows6.1-KB20285
    60-v2-x86.msu

    64bit
    http://download.microsoft.com/download/F/1/A/F1A02F0C-0F64-4E87-9BC1-EFA8CDE464FE/Windows6.1-KB20285
    60-v2-x64.msu

  4. Wouldn’t it be worth talking to Microsoft and seeing if they can patch the underlying issue too?

  5. @Jo
    I tried that. Seems that the font service still starts too late to be useful.

    @Ian
    John is working with Microsoft on this.