Categories
Mozilla

Asychronous Storage Statements Just Got Faster

One of the complaints I received early on about the asynchronous storage API was that it wasn’t faster to call executeAsync compared to execute or executeStep on the calling thread. This was largely the case because people were testing the function call without any other IO going on, which isn’t going to always be the case for our users. People tend to have more than one application running on their computer doing something, and that something can often hit the disk. The culprit of the slowdown was recreating the sqlite3_stmt object for each call to executeAsync.

With my work on the asynchronous location bar, I wanted to speed up the call to executeAsync to make it as fast as possible so autocomplete look ups would be quick. To accomplish this, we now cache the asynchronous sqlite3_stmt object so we don’t recreate it on every call to executeAsync. This amortizes the cost that was causing the asynchronous API to be slower than the synchronous one.

This solution is not sufficient, however, if you bind parameters to the statement before calling executeAsync. This is because binding parameters stores state on the underlying sqlite3_stmt object, and we can’t store that information on it because it could be in use on the background thread. To get around this issue, I reuse a code from the recent asynchronous storage API addition to store the bound values in memory and then bind them at the time of execution on the background thread. Andrew Sutherland and I were both very happy at how small this patched ended up being as a result of good API design in the past.

The bonus with this two step solution is that we’ve also completely removed the possibility of lock contention inside of the SQLite library on the calling thread of executeAsync. If you have a long running sqlite3_step command on the background thread, this could block your call to one of the binding calls or executeAsync, which is undesirable.

This code is checked in on mozilla-central, and will be a part of Gecko 1.9.2.

Categories
Mozilla

Test Build: Asynchronous Location Bar (Take >2)

I have another test build for folks to try out. This fixes a possible error condition that could happen in certain circumstances. This build has two known issues:

  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.

Categories
Mozilla

Test Build: Asynchronous Location Bar

It’s been a while, but last week I started working on the asynchronous location bar patch again. The add-on from past posts will not be updated as there are binary changes that need to be made. I do, however, have some test builds that you can try out. These are built of off mozilla-central, so it’s like using a 3.6 nightly. That means it may not be stable, and you shouldn’t use this with your default profile (but feel free to copy your places.sqlite file into a new one to really hammer on it). If you are interested in trying it out, the builds can be found here.

Your feedback is appreciated!

Categories
Mozilla

New Asynchronous Storage API Has Landed

Some time in January I spec’ed out and API to allow the binding of multiple sets of parameters to a prepared statement and execute it asynchronously. This could be done in the past, but it was difficult and resource intensive to do (you would have to first clone the statement that you had and then bind and then pass all the clones to executeAsync). Say you want to insert a number of rows into a table now. Your code will look something like this:

// Note: db is the mozIStorageConnection for our database.
var stmt = db.createStatement("INSERT INTO table_name (table_value)" +
                              "VALUES (:value)");
var values = [
  "val1",
  "val2",
  "val3",
];
var array = stmt.newBindingParamsArray();
for (let i = 0; i < values.length; i++) {
  let params = array.newBindingParams();
  params.bindByName("value", values[i]);
  array.addParams(params);
}
stmt.bindParameters(array);
stmt.executeAsync(); // This will insert all the values into the table.

It's not the prettiest thing in the wold, and I hope to add some language helpers for JavaScript to make this even easier to use from JavaScript. Hope you find it useful!

Categories
Mozilla

Asynchronous Location Bar Searches

For those of you using the asynchronous location bar add-on, today’s nightly of both mozilla-central and mozilla-1.9.1 should show a reduction in memory use. Turns out there was a bit of a leak in mozStorage that would mean you’d get high memory usage that would never go down. My bad.

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.