If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
No announcement yet.
Mozilla's Servo Still Going Forth To Parallelize The Web
It is clear you have not used Firefox recently with a lot of bookmarks. Such magnificent and wise decisions they were to have it all in SQLite, which consequently fsync()s in the UI thread.
SQLite only calls `fsync` at the end of a transaction. For a read-only operation like viewing the bookmarks, there's certainly no `fsync` happening. Firefox's responsiveness problems aren't caused by using a storage backend with transaction support. Chromium certainly makes use of transactions to prevent data loss and recover from being killed just like Firefox but it doesn't have any of these problems.
There's a pretty clear correlation there, as the UI stall complaints increased a lot right after FF moved to sqlite.
That issue wasn't from bookmarks, but the history. When you visit a webpage, it gets stored in the history, and you can search for it in the awesomebar. That's where all the fsyncs came from.
As i mentioned earlier, there was a big effort a while back to move all that IO, both reading and writing, into async calls running in background threads. It seems like maybe that was around FF17-18 or so, but i don't recall exactly.