IndexedDB very slow compared to WebSQL, what am i doing wrong?

Question

I made a demo chrome extension to compare websql and indexeddb and to learn how both worked in more detail.

To my surprise it showed that indexeddb is a lot slower even compared to the most naive sql command.

Since websql have been deprecated in favor of indexeddb i assumed indexeddb would be as fast or faster than websql.

I'm assuming i'm doing something wrong in the indexeddb code. Because deprecating something that is much faster would be stupid and i assume they knew what they were doing when deprecating websql in favor of indexeddb.

The sql search code:

// Search entries
        var term = search_query;
        db.transaction(function(tx) {
            tx.executeSql('SELECT * FROM places', [], function (tx, results) {
                console.log("sql search");
                var count = 0;
                var wm = WordsMatch.init(term.trim().toLowerCase());
                var len = results.rows.length
                for (var i = 0; i < len; ++i) {
                    var item = results.rows.item(i);
                    if (wm.search(item.url.toLowerCase())) {
                        //console.log(item.id, item.url);
                        ++count;
                    }
                }
                console.log("Search matches:", count);
                console.log("\n");
            });
        }, reportError);

The indexeddb search code:

    PlacesStore.searchPlaces(search_query, function(places) {
                    console.log("indexedDB search");
                    var count = places.length;
                    console.log("Search matches:", count);
                    console.log("\n");
                });

var PlacesStore = { searchPlaces: function (term, callback) {
        var self = this,
            txn = self.db.transaction([self.store_name], IDBTransaction.READ_ONLY),
            places = [],
            store = txn.objectStore(self.store_name);
        var wm = WordsMatch.init(term.trim().toLowerCase());
        Utils.request(store.openCursor(), function (e) {
            var cursor = e.target.result;
            if (cursor) {
                if (wm.search(cursor.value.url.toLowerCase())) {
                    places.push(cursor.value);
                }

                cursor.continue();
            }
            else {
                // we are done retrieving rows; invoke callback
                callback(places);
            }
        });
    }
}/**/


var Utils = {
    errorHandler: function(cb) {
        return function(e) {
            if(cb) {
                cb(e);
            } else {
                throw e;
            }
        };
    },

    request: function (req, callback, err_callback) {
        if (callback) {
            req.onsuccess = function (e) {
                callback(e);
            };
        }
        req.onerror = Utils.errorHandler(err_callback);
    }
};

I have also made a chrome bug report and uploaded the full extension code there: http://code.google.com/p/chromium/issues/detail?id=122831

(I cant upload the extension zip file here, no such feature)

I filled both websql and indexeddb databases each with 38862 urls that i used as test data.

Answer 1

Part of the problem is that IndexedDB implementations have so far mostly been working on getting the full spec implemented, and less focused on performance. We recently found some really stupid bugs in Firefox which got fixed and should make us significantly faster.

I know the chrome team has suffered some challenges because of their multi-process architecture. I'm told that they've fixed some of these issues recently.

So I'd encourage you to try the latest version of all browsers, possibly including nightly/canary builds.

However note that we didn't deprecate WebSQL because IndexedDB was faster. We deprecated WebSQL because it wasn't future proof. WebSQL was defined to use a specific SQLite backend (if you look at the spec it's actually written clearly there). However all browser manufacturers need to use the latest version of SQLite in order to pick up security, performance and stability fixes. And the latest versions always change the SQL syntax in subtle ways. Which means that we would have broken your WebSQL-using web applications in subtle ways. This didn't seem ok to us.