Luckily, the fix was trivial. Now we handle the enter keypress immediately when the user hits it, and not later. Problem solved :)

Background

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.

1. There is a lot of flickering when new results show up. This is being tracked in bug 393902.
2. Your computer will hang for a period of time (it will become responsive again) if you continue to type once no results are found. This is being tracked in bug 503701.

This is built off of a “stable” point of mozilla-central, so it’s like using a 3.6 nightly. All the normal warnings apply about using it. I’m told this greatly increases the speed at which results obtained by many people. If you experience any issues (other than the two listed here), please let me know! The builds can be found here.

Your feedback is appreciated!

For those of your programmers out there, I have a word of advice. Always make sure you have a virtual destructor in your base class. If you don’t, you could spend days tracking down a leak that doesn’t seem to make sense. Of course, this probably would have been spotted earlier if we reported leaks in xpcshell unit tests.

Without further delay, here is the new test build.

I’ve also made a handy little add-on that lets you test this out. I haven’t tested this add-on extensively, but it should work out OK. If you think you see a bug, try the test build first before reporting it please.

Still want your feedback on if you think the results are faster, slower, or about the same, so please follow-up!

Now that it’s passing all tests, I feel comfortable posting a test build for folks to try and see if it helps or not. I should note that the current implementation is pretty dumb and doesn’t take many opportunities speed up results. Additionally, there are some other performance wins that are on my mind that become a lot easier to do with this newer implementation.

Admittedly, I haven’t benchmarked this yet, so I don’t know how it compares to the existing code. During causal use, however, it feels no slower than the existing implementation, but I don’t usually have issues with it. The goal here is to help out those who do have performance issues with the location bar. In fact, that’s exactly the feedback I’m looking to get. So, if you are feeling ambitious and willing to live on the wild side for a bit, I’d like you try this test build. After a little bit of use, let me know if you think the results are faster, slower, or about the same. Note: this is build off of mozilla-central, so it’s like a 3.2a1pre build.

Your feedback is greatly appreciated!