// 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!

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.

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.

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!

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!

I will no longer be developing my first add-on, the Rooster Teeth Site Extender. I’ve established that I simply do not have time to maintain it, or do the reviews. It’s disappointing to both me, and its users to have an owner who isn’t really owning it.

Now for the good news. I just saved a bunch of money on my car insurance - er, wait. That’s not it. There is a new maintainer! In fact, I’ve already transferred the ownership of the project over to him. He cares a lot more about the project than I do, so it’s a good fit.

You can still report bugs in the same place as before, but I’m just a consultant of the project now. I wish the project luck, and it’s been fun while it lasted!

Rejoice!

That’s right! You can now selectively clear data from a domain (and all of it’s sub domains) with two clicks of the mouse! This tries to clear everything we know about a site, with the exception of bookmarks. There are still a number of issues pending with this to make it even more powerful (help wanted!), but as it stands, it’s pretty nice. I am, of course, biased.

All this work made it in for Firefox 3.1 beta 2, but I’ve been lazy and am just now getting to it.