6 ms·

20-line patch to Firefox 4 that makes startup on Windows 2x as fast

117 points by joshfraser 16y ago

xpaulbettsx 16y ago
Hmmm, so I suspect in practice that you're not going to see this kind of difference usually - since he's probably testing on a binary he just built, SuperFetch (the built in OS prefetcher) hasn't had a chance to determine what pages are usually used by Firefox. Once you've used FF as your browser for awhile, SuperFetch will know better and won't do as badly. That being said, this trick will probably beat SuperFetch, since they know up front that they'll be using big chunks of xul.dll. Don't do this in every app though, or else every app in the system is just chewing through IOs on pages they might not actually be using.
- holygoat 16y ago
  No, it won't have a big effect on warm or OS-optimized startup time... but cold startup time, especially for new releases, is a big area of concern, so it's nice to see wins there!
  - simcop2387 16y ago
    While I doubt my specific hypothetical case will actually exist... I think it should also help if the OS has decided not to prefetch the dll for you for some reason. I don't believe it should ever actually hurt but should make it a lot nicer on any of the possible edge cases.
- slightlyoff 16y ago
  SuperFetch only hits the first 10 meg of a DLL. If any of these are larger than that, you'll still see significant thrashing on pages located further back in the binaries. I implemented a similar solution for chrome.dll last summer and it had a gigantic effect on cold start times. Glad to see Mozilla prioritizing startup too.
  - asadotzler 16y ago
    Alex, can you link the bug(s) or patch set for your similar changes?
    - mihaip 16y ago
      http://crbug.com/45510 http://crbug.com/45510, http://crrev.com/50386 http://crrev.com/50386, http://crrev.com/51486 http://crrev.com/51486, http://crrev.com/51594 http://crrev.com/51594 and http://crrev.com/54934 http://crrev.com/54934 seem to be appropriate links.
    - slightlyoff 16y ago
      Mihai covered it. Here's my rundown: http://infrequently.org/2011/01/on-the-care-and-feeding-of-spinning-disks/ http://infrequently.org/2011/01/on-the-care-and-feeding-of-s...
  - JonnieCache 16y ago
    >SuperFetch only hits the first 10 meg of a DLL. If any of these are larger than that, you'll still see significant thrashing on pages located further back in the binaries Yuck. Is there a good engineering reason for this reliance on the physical location of code within a lib file rather than its logical internal structure? I guess its a compromise they made after running some studies. Still seems sickeningly ugly though. Just like the trick the OP was forced to implement to override this behaviour. Yucketty yuck yuck.
    - slightlyoff 16y ago
      Define "logical internal structure"? Most code in a library won't be differentiated by use unless you can provide WPO or PGO-based feedback that you trust as representative. As for the next obvious question ("why not just read in the whole thing?"), I think you can probably guess. I'm not sure how yucky this is. The world is analog. MSFT made things go faster without asking developers to change anything they were doing. I wish more OSes showed more of this sort of user-centric, data-driven prioritization of feature development.
blago 16y ago
After using FF for 5 years it got so slow on my Mac that it became unusable. I made the switch to Chrome last year and I'm not looking back. I was an early adopter and supporter (including money) but FF is no longer what it used to be. The code base is bloated, performance is sluggish, they don't seem to care about developers anymore (websql anyone, lack of officially supported debugging tool). All of this in spite of cream-of-the-crop tallent that they have acquired in the last few years. I keep asking mysel and just can't figure: how did it all go so wrong.
- code_duck 16y ago
  FF4 has significantly improved performance, at least. It's much more on par with Chrome and Safari than 3.x.
  - eiji 16y ago
    I think FF needs a way to benchmark extensions. It's true, without SSD, FF3.X cold-start is not what it should be. However, many users do face an interesting dilema. They complain about slow startup time, and at the same time, call themselfs power-users with 10+ extensions, which makes it hard to switch browsers. The recent Skype-disaster highlighted the problem of missing extension-benchmarks for the public. I don't know how that could be done, but besides the 5-star ratings, there could be a mozilla-provided performance indicator. FF4 does improve performance, but power-users will still use the same extensions.
    - mbrubeck 16y ago
      We're working on benchmarking extensions' effect on startup time: https://bugzilla.mozilla.org/show_bug.cgi?id=623950 https://bugzilla.mozilla.org/show_bug.cgi?id=623950
- bzbarsky 16y ago
  > The code base is bloated Evidence? > performance is sluggish In 3.6, right? 4.0 improves on a lot of that. > websql Which pretty much everyone developing web browsers and working on the relevant standards now agrees was a bad idea, last I checked (if nothing else because it can't be sanely standardized). Firefox 4 is shipping with IndexedDB, if you note. > they have acquired in the last few years And who have been working on Firefox 4. Firefox 3.6 branched from trunk in August 2009... Yes, the release cycle is too long; that's being fixed.
ot 16y ago
Taras Glek's blog (http://blog.mozilla.com/tglek http://blog.mozilla.com/tglek) contains a lot more information about link optimizations to improve startup times of Firefox. One of the reasons why loading libxul is so slow normally is that the chain of constructors called at initialization time is arranged backwards in the library (http://blog.mozilla.com/tglek/2010/05/27/startup-backward-constructors/ http://blog.mozilla.com/tglek/2010/05/27/startup-backward-co...) so the OS (which is usually optimized for forward loading) cannot efficiently prefetch the pages. There is also a post that explains how they measure the startup time on Windows (http://blog.mozilla.com/tglek/2010/10/04/diagnosing-slow-startup/ http://blog.mozilla.com/tglek/2010/10/04/diagnosing-slow-sta...) and Unix (http://blog.mozilla.com/tglek/2011/01/14/builtin-startup-measurement/ http://blog.mozilla.com/tglek/2011/01/14/builtin-startup-mea...).
ck2 16y ago
Pretty please put this in Firefox 3.6.15 as well because it will be quite some time before many power-users can upgrade to 4.0
mbrubeck 16y ago
(disclosure: I work for Mozilla) The 2x improvement is for cold startup on specific configurations, mainly on hard drives with slow seek times. For faster hard drives, the improvement is less, and for SSDs it may be much less. I should also note this is just one of many startup speed improvements coming in Firefox 4.
- kloc 16y ago
  There are lot of user with slow machines in developing nations. They are typically using a pirated copy of windows xp on a slow hardware and since initially microsoft didn't allow upgrade to IE 7 on pirated copies, lot of people moved to firefox. They would certainly enjoy the fast startup time.And considering that lot of such people are there( it was in the news that Ballmer told Hu that 90 percent of China is using pirated windows) it is still a big win for firefox usuability overall.

117 points by joshfraser 16y ago

Hmmm, so I suspect in practice that you're not going to see this kind of difference usually - since he's probably testing on a binary he just built, SuperFetch (the built in OS prefetcher) hasn't had a chance to determine what pages are usually used by Firefox. Once you've used FF as your browser for awhile, SuperFetch will know better and won't do as badly. That being said, this trick will probably beat SuperFetch, since they know up front that they'll be using big chunks of xul.dll. Don't do this in every app though, or else every app in the system is just chewing through IOs on pages they might not actually be using.

holygoat 16y ago
No, it won't have a big effect on warm or OS-optimized startup time... but cold startup time, especially for new releases, is a big area of concern, so it's nice to see wins there!
- simcop2387 16y ago
  While I doubt my specific hypothetical case will actually exist... I think it should also help if the OS has decided not to prefetch the dll for you for some reason. I don't believe it should ever actually hurt but should make it a lot nicer on any of the possible edge cases.
slightlyoff 16y ago
SuperFetch only hits the first 10 meg of a DLL. If any of these are larger than that, you'll still see significant thrashing on pages located further back in the binaries. I implemented a similar solution for chrome.dll last summer and it had a gigantic effect on cold start times. Glad to see Mozilla prioritizing startup too.
- asadotzler 16y ago
  Alex, can you link the bug(s) or patch set for your similar changes?
  - mihaip 16y ago
    http://crbug.com/45510 http://crbug.com/45510, http://crrev.com/50386 http://crrev.com/50386, http://crrev.com/51486 http://crrev.com/51486, http://crrev.com/51594 http://crrev.com/51594 and http://crrev.com/54934 http://crrev.com/54934 seem to be appropriate links.
  - slightlyoff 16y ago
    Mihai covered it. Here's my rundown: http://infrequently.org/2011/01/on-the-care-and-feeding-of-spinning-disks/ http://infrequently.org/2011/01/on-the-care-and-feeding-of-s...
- JonnieCache 16y ago
  >SuperFetch only hits the first 10 meg of a DLL. If any of these are larger than that, you'll still see significant thrashing on pages located further back in the binaries Yuck. Is there a good engineering reason for this reliance on the physical location of code within a lib file rather than its logical internal structure? I guess its a compromise they made after running some studies. Still seems sickeningly ugly though. Just like the trick the OP was forced to implement to override this behaviour. Yucketty yuck yuck.
  - slightlyoff 16y ago
    Define "logical internal structure"? Most code in a library won't be differentiated by use unless you can provide WPO or PGO-based feedback that you trust as representative. As for the next obvious question ("why not just read in the whole thing?"), I think you can probably guess. I'm not sure how yucky this is. The world is analog. MSFT made things go faster without asking developers to change anything they were doing. I wish more OSes showed more of this sort of user-centric, data-driven prioritization of feature development.

blago 16y ago

After using FF for 5 years it got so slow on my Mac that it became unusable. I made the switch to Chrome last year and I'm not looking back. I was an early adopter and supporter (including money) but FF is no longer what it used to be. The code base is bloated, performance is sluggish, they don't seem to care about developers anymore (websql anyone, lack of officially supported debugging tool). All of this in spite of cream-of-the-crop tallent that they have acquired in the last few years. I keep asking mysel and just can't figure: how did it all go so wrong.

code_duck 16y ago
FF4 has significantly improved performance, at least. It's much more on par with Chrome and Safari than 3.x.
- eiji 16y ago
  I think FF needs a way to benchmark extensions. It's true, without SSD, FF3.X cold-start is not what it should be. However, many users do face an interesting dilema. They complain about slow startup time, and at the same time, call themselfs power-users with 10+ extensions, which makes it hard to switch browsers. The recent Skype-disaster highlighted the problem of missing extension-benchmarks for the public. I don't know how that could be done, but besides the 5-star ratings, there could be a mozilla-provided performance indicator. FF4 does improve performance, but power-users will still use the same extensions.
  - mbrubeck 16y ago
    We're working on benchmarking extensions' effect on startup time: https://bugzilla.mozilla.org/show_bug.cgi?id=623950 https://bugzilla.mozilla.org/show_bug.cgi?id=623950
bzbarsky 16y ago
> The code base is bloated Evidence? > performance is sluggish In 3.6, right? 4.0 improves on a lot of that. > websql Which pretty much everyone developing web browsers and working on the relevant standards now agrees was a bad idea, last I checked (if nothing else because it can't be sanely standardized). Firefox 4 is shipping with IndexedDB, if you note. > they have acquired in the last few years And who have been working on Firefox 4. Firefox 3.6 branched from trunk in August 2009... Yes, the release cycle is too long; that's being fixed.

ot 16y ago

Taras Glek's blog (http://blog.mozilla.com/tglek http://blog.mozilla.com/tglek) contains a lot more information about link optimizations to improve startup times of Firefox. One of the reasons why loading libxul is so slow normally is that the chain of constructors called at initialization time is arranged backwards in the library (http://blog.mozilla.com/tglek/2010/05/27/startup-backward-constructors/ http://blog.mozilla.com/tglek/2010/05/27/startup-backward-co...) so the OS (which is usually optimized for forward loading) cannot efficiently prefetch the pages. There is also a post that explains how they measure the startup time on Windows (http://blog.mozilla.com/tglek/2010/10/04/diagnosing-slow-startup/ http://blog.mozilla.com/tglek/2010/10/04/diagnosing-slow-sta...) and Unix (http://blog.mozilla.com/tglek/2011/01/14/builtin-startup-measurement/ http://blog.mozilla.com/tglek/2011/01/14/builtin-startup-mea...).

ck2 16y ago

Pretty please put this in Firefox 3.6.15 as well because it will be quite some time before many power-users can upgrade to 4.0

mbrubeck 16y ago

(disclosure: I work for Mozilla) The 2x improvement is for cold startup on specific configurations, mainly on hard drives with slow seek times. For faster hard drives, the improvement is less, and for SSDs it may be much less. I should also note this is just one of many startup speed improvements coming in Firefox 4.

kloc 16y ago
There are lot of user with slow machines in developing nations. They are typically using a pirated copy of windows xp on a slow hardware and since initially microsoft didn't allow upgrade to IE 7 on pirated copies, lot of people moved to firefox. They would certainly enjoy the fast startup time.And considering that lot of such people are there( it was in the news that Ballmer told Hu that 90 percent of China is using pirated windows) it is still a big win for firefox usuability overall.