Tag: places

Categories
Mozilla

Query Performance Monitoring

Over in bug 481261 I am adding support in mozStorage to warn when a query doesn’t use an index to sort. This is a debug only warning that uses NS_WARNING to tell you what query is at fault, and the total number of sort operations that were used on it.

Luckily, SQLite exposes a handy function that tells us this information. In general, you want to use a index in your ORDER BY clause so SQLite can use it to generate the order the results a given back. If you do not use an index, SQLite has to first get all the results in memory, then it sorts them, and then it starts to return results. If you expect a lot of results, this can get very expensive.

There were suggestions on the newsgroups to also add an API so debuggers such as ChromeBug or SQLite Manager could listen for these types of errors. I’ll be filing follow-up bugs for some of these suggestions later on.

Categories
Mozilla

More fsync and write Reduction

As you may or may not be aware, my personal mission as of late is to reduce the number of writes and fsyncs that Firefox makes, and move the ones that we do have to make off of the main thread. The primary target here has been Places, and the work is still continuing.

The Firefox team has been focusing on code sprints to get some small well scoped things done for Firefox 3.1 since we’ve got a bit more time. My latest sprint can be found over in bug 480211, where I’ve removed a write and fsync that we used to do after every page visited. If we had enough pages in history that were old enough, we would remove them from history. We now do this off of the main thread, asynchronously at the same time we flush data from our temporary tables to our permanent ones. The net result is the same number of writes and one less fsync. Additionally, the write is no longer done on the main thread.

Sadly, I couldn’t measure any real-world performance gains with my DTrace scripts – in fact I saw no change during several different runs of Tp3 with various places.sqlite files. It’s quite possible I did not have the conditions setup correctly to have pages expiring, and I could have spent a few more hours generating just the right places.sqlite file to demonstrate wins in the real world, but the theory behind the patch is pretty simple. The gain is pretty obvious.

Just another drop in the bucket of performance wins for Firefox. Stay tuned, as there is more to come!

Categories
Mozilla

Test Add-on: Asynchronous Location Bar Searches (Take 3)

It seems as though the past builds still had issues on Windows. Mook was kind enough to get be a stack of the hang on shutdown folks were seeing, and I’ve modified the code to avoid making that happen (still not sure why it happened, but I know how it could get there – bug is filed). Without further delay, here’s an add-on that you can try out with the latest fixes in! I’ve been told on irc that this one works much better on Windows.

Categories
Mozilla

Test Build: Asynchronous Location Bar Searches (Take 2)

It turns out that I neglected to make the all-important packages-static file changes that would actually result in a build that works for most folks in my previous test builds. I thought I had fixed that with the last build, but apparently I never submitted it to the try server (I had the line in my terminal all ready to just press enter though!).

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!

Categories
Mozilla

Test Build: Asynchronous Location Bar Searches

A few months ago I decided to try to use the asynchronous storage API that was added in Firefox 3.1 to help reduce the pain of disk IO on the main thread. Sadly, it became quite apparent that this was going to be too big of a change and need to much work to make it into 3.1, so I put off doing any more work on it. However, this week I started working on the patch again, updating it to work with the changes to the location bar and the storage back-end. Today I finally got it passing all of our existing tests (although, I know of at least one condition where it fails and is untested).

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!