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

2

6

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.

Mercuric answered 11/4, 2012 at 8:38 Comment(0)
O
15

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.

Obeisance answered 15/6, 2012 at 23:30 Comment(3)
That's amazing that only Mozilla has this problems with SQLite. Android, iOS, Symbian and thousands of other developers love SQLite.Thrombosis
Are chrome and firefox's versions of indexeddb still slow? *relativeRamose
Yea, first it was performance, sharding (sharding - on a single computer ??? that's bs) now security - the funny thing is that indexed-db uses SQLite under the hood - LoL - but by that argumentation, it can't because security fixes and syntax changes would break IndexedDB.Harmonist
A
8

Answer: You're not doing anything wrong. Your IndexedDB code is correct. As for the conclusion, others have found this to be true as well.

Extra: One interesting thing to note is that IndexedDB is implemented differently across browsers. Firefox uses SQLLite and Chrome LevelDB, so even if you're using IndexedDB in FF you're still using a SQL-backed technology with SQL-like overhead (plus everything else).

I would be curious to see your results at different sized databases. I would hope, but cannot yet confirm, that IndexedDB would scale better across larger datasets (even though 38862 does seem sufficiently large).

Abeabeam answered 11/4, 2012 at 17:48 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.