Last week I landed bug 485976 which moves the writing and subsequent fsync (or flush on windows) call to a background thread. This should benefit all of our users, especially those with slower hard drives. Paul O’Shannessey has filed another bug that will reduce the amount of disk activity substantially more that will benefit our users even more.
Background
Session restore writes out to disk very frequently – every ten seconds, in fact. This behavior is controllable by the preference browser.sessionstore.interval for those who want to reduce that, but then you run the risk of not having all your data saved if you crash. We really don’t want to reduce that time for our users.
The amount of data that is written out to disk by session restore scales linearly with the number of tabs and windows you have open. The more you have, the more data has to be written out to disk, and the longer it is going to take.
As we learned in the past with Places, writing to disk and calling fsync can be painfully slow. In session restore code, we are doing this very often and on the main thread. Clearly, this is a bad thing.
Process and Solution
This section is a bit technical, so feel free to skip it. The short answer is “do not block the main thread while writing and flushing data to the hard drive.”
We wanted to address this problem as much as we could for Firefox 3.6. In order to actually reduce the number of writes and fsync calls, we would have to heavily modify how session restore manages and writes its data. That is a big change that we were not comfortable doing this late in the 3.6 cycle. On top of that, we do not really have the manpower to do that change since the people who know that code well are working on other performance improvements for this release. The simple solution for now then is to move our write and fsync calls off of the main thread.
Luckily, Boris Zbarsky had recently written a new API for JS consumers to asynchronously copy an input stream to an output stream. This API would work great for session restore! We had to fix one minor issue with the underlying code not properly handling nsISafeOutputStreams (which make sure we fsync properly), but once that was done, the fix was incredibly simple.
4 replies on “Session Restore Now Writes to Disk Off of the Main Thread”
Is there any chance that with enough tabs/windows the session write would take more than browser.sessionstore.interval? Could this cause session writes to stack up or does the code check to see if a write is already in progress? Would Firefox end up blocking other applications from accessing the hard drive in a situation like this?
It’s possible if you set the value low enough or you have an excessive number of tabs and and exceptionally slow file system. The nsISafeFileOutput stream would ensure that you don’t get corruption in these cases, however.
Firefox shouldn’t block other applications from accessing the hard drive, but that really depends on your file system.
[…] Fixed: 485976 – Move writing sessionstore.js off the main thread. (Shawn’s blog post) […]
Do you realize that this single issue is the largest Firefox performance disaster I’ve ever seen?
I just spent WEEKS troubleshooting the crap out of this problem, and could not solve it. I was tracing stacks on Firefox.exe threads in Process Explorer, debugging memory dumps in WinDbg, running safe mode, trying processor optimized builds, reverting to FF 3.5.0, reverting to FF 3.0.13, swapping out my Sessionstore.js, etc.
TONS of people on the Mozilla firefox support forums are complaining, there is an endless amount of threads talking about sluggish performance and problems scrolling, stuttering when entering text, etc.
Only today did I FINALLY solve this with the browser.sessionstore.interval.
Seriously, look at how many comments there are sympathizing with this fix:
http://www.reddit.com/r/todayilearned/comments/9by73/til_firefox_backs_up_your_tabs_every_10_seconds/
Here’s a guy who bought a new PC JUST because of this issue (he thought his PC was the problem.) http://lifehacker.com/5342636/how-to-fix-annoying-youtube-jumpiness-in-firefox
http://www.ncwoodworker.net/forums/f57/firefox-trick-fixes-freezing-25512/
“I was blown away by the results.” “it is incredible how fast it is.”
This issue caused me and thousands of others (tens, hundreds of thousands?) a huge amount of aggravation. I am very relieved to finally get this monkey off my PC’s back, so to speak.