Skip navigation

About two weeks ago the asynchronous location bar work landed in mozilla-central without much issue. It’s also in the Firefox 3.6 alpha we just recently released. This has the potential to impact all of our users, but those on slower hard drives will notice this the most. Your location bar searches may not complete any faster than before, but they certainly won’t be hanging your browser and locking up the UI.


We’ve been getting reports for some time about the location bar hanging the application for some users when they are typing in it. This wasn’t a problem that was reproducible on every machine, and even on machines that saw it, it wasn’t always 100% reproducible. Clearly, this behavior is not desirable, so we set out to fix it.

I had a theory to the cause almost a year ago and filed a bug that I was hoping we could work on and fix for Firefox 3.5. We knew that reading data off a disk can be slow (and certainly would complete in a non-deterministic amount of time). Since SQLite uses blocking read calls (no more code can execute until the data is read from disk), this could certainly be the cause of the slowdown our users were seeing. Some simple profiling showed that this was largely the cause of the hanging. Work began on the project, but it was clear that enough issues were cropping up that we were not going to be able to safely take this change for Firefox 3.5, and resources were diverted elsewhere.

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 reading from the hard drive.”

In order to not block the main thread while reading from disk we either need to make SQLite use non-blocking read system calls, or call into SQLite off of the main thread. Changing the SQLite code isn’t something we want to do, so that solution was out of the question. Luckily, we had solved a similar problem with writes and fsyncs earlier in the Firefox 3.5 development with the asynchronous Storage API.

The first implementation that we tried essentially did the same thing that the old code did. We would execute a query, but this time asynchronously, and then process the results and see if they match. There were two issues with this approach, however. The first issue was that we were filtering every history and bookmark entry on the main thread for a given search. That could be a lot of work we end up doing, and with the additional overhead of moving data across threads, the common case would see no win. The second issue was that once we selected a result in the location bar, and a search was not yet complete, there would be a hang as the main thread processed a bunch of events that Storage had posted to it containing results.

At this point, we realized we needed to do the filtering on a thread other than the main thread. After some thought, we was figured that the easiest way to do that would be to use a SQL function that we define in the WHERE clause of our autocomplete queries. This way, all the filtering is done on a background thread, and the code that runs on the main thread only deals with results we will actually use. This solution exposed some things in the Storage backend like lock contention and a few other subtle issues, but nothing major came up.

For more details on how the location bar search results are generated, see my explanation here.

If you weren’t having a problem before, chances are you won’t notice any difference at all.


    • Dan
    • Posted August 11, 2009 at 13:03 (1:03 pm)
    • Permalink

    I have noticed now that when I quickly type an address and hit enter (all in one go, bypassing the awesomebar) then the enter doesn’t seem to be processed until after the results have been returned. This is normally the case when the domain is short and I can type it out and press enter quicker than typing part of it, waiting for the results, pressing the down arrow and then pressing enter.

    • Ian M
    • Posted August 12, 2009 at 00:46 (12:46 am)
    • Permalink

    Will this thread run on a different core on a multi-core computer, or is it still all single threaded?

    • AV
    • Posted August 12, 2009 at 01:13 (1:13 am)
    • Permalink

    Perhaps because I’m a lousy typist or perhaps because I have a very old PC, I find that because of bug 503701, results are very often slower to appear than before.

    • Igor
    • Posted August 12, 2009 at 03:10 (3:10 am)
    • Permalink

    I can confirm what Dan said, it’s been happening since Async bar has landed and still happens in the latest nightlies. It does happen even when the domain name isn’t short and has already been found by the bar, and the delay in registering the enter is quite long.

    • biesi
    • Posted August 12, 2009 at 07:14 (7:14 am)
    • Permalink

    Is this what makes the dropdown take forever to go away, and consequently what makes pressing enter take forever to take effect? (forever = ~1 sec or so)

  1. This would run on a different core. Contrary to popular belief, Firefox hasn’t been single threaded in a very very long time.

  2. None of you have the add-on installed, right? This is the first I’ve heard of the issue (why aren’t people filing bugs?)

    • Dan
    • Posted August 12, 2009 at 10:22 (10:22 am)
    • Permalink

    Fair point, bug filed.

    I have never installed the prototype extension.

2 Trackbacks/Pingbacks

  1. […] This is analogous to a recent discussion of the asynchronous AwesomeBar. ↩ […]

  2. By Swing and a Miss : Shawn Wilsher on 02 Sep 2009 at 1:48 pm

    […] we landed the asynchronous location bar, some people started to see substantially slower results. This was alarming since it was supposed […]

Comments are closed.