A simple traversal in an indexedDB containing 2000 entries is ~3x slower in Firefox Desktop than in Chrome 38. The test included has been tried several times in different environments with the same outcome. Steps to reproduce: - Go to http://sergimansilla.com/idb-benchmarks/ - Click the 'GenerateContacts' button. This will generate 2000 random contacts and write them in the database. - Click the 'Search' button, this is the actual traversal. The results and the total traversal time will be shown. You can find the source code at https://github.com/sergi/idb-benchmarks/blob/master/main.js

I measured the same with 35.0a1 (2014-09-16) which I believe should have the new IDB PBackground code.

(In reply to Ben Kelly [:bkelly] from comment #1) > I measured the same with 35.0a1 (2014-09-16) which I believe should have the > new IDB PBackground code. Did you profile? I wonder if we're spending time in JS, IPC, or the database work.

(In reply to ben turner [:bent] (use the needinfo? flag!) from comment #2) > Did you profile? I wonder if we're spending time in JS, IPC, or the database > work. I did not profiled it. I just verified it still reproduced with the newer code. Note, however, this was on non-e10s, so no IPC should be going on. One thing that was unclear to me was how to get a profile that included all the IDB threads. I seem to recall the profile only grabbed the main thread and perhaps the compositor thread. Maybe thats a b2g thing, though.

Sorry, s/IPC/IPDL/.

Here's a profile with main thread and the PBackground thread: http://people.mozilla.org/~bgirard/cleopatra/#report=bd99c34b4bf48bb7c9a2c56f3506f757ee8c005a I'm not sure what thread names to specify to get IDB to show up.

Searching for "IDB" shows that the action is all at the start of the profile in comment 5. It appears that the main thread is mainly waiting for responses from IDB.

Here's a profile with the quota IO thread and IDB transaction thread added in: http://people.mozilla.org/~bgirard/cleopatra/#report=7ed2758793813a743060b94d908ce0b29b5dd225 Still don't see much.

A continue call sends a ContinueParam to IDB PBackground and then DoDatabaseWork() in transaction thread pool. The reponse is sending back reversely, i.e., each continue() includes four IPCs.

(In reply to Ting-Yu Chou [:ting] from comment #8) > i.e., each continue() includes four IPCs. Well, two IPC messages and two thread switches in the parent process.

(In reply to ben turner [:bent] (use the needinfo? flag!) from comment #9) > (In reply to Ting-Yu Chou [:ting] from comment #8) > > i.e., each continue() includes four IPCs. > > Well, two IPC messages and two thread switches in the parent process. You're right, thanks for the correction.

I modified the test a bit to traverse the database only (http://janus926.github.io/idb-benchmarks/), ran the test 10 times on my desktop (Ubuntu 14.04): Chrome version 38.0.2125.122 (64-bit) Mean: 57.9ms Standard deviation: 16.39 Median: 50ms Firefox nightly 36.0a1 216080:2a292d225ec0 (e10s disabled): Mean: 143.2ms Standard deviation: 10.34 Median: 141.5ms Then I tried to get timestamps for the ipc messages and thread switching, here's one sample: 2412.175373126 IDBCursor::Continue 2412.175381555 BackgroundCursorChild::SendContinueInternal > SendContinue 2412.175401119 Cursor::RecvContinue (+20us) 2412.175413496 TransactionThreadPool::TransactionQueue::Dispatch 2412.175430693 ContinueOp::DoDatabaseWork (+17us) 2412.175507666 ContinueOp::SendSuccessResult (+77us, includes the duration of DoDatabaseWork()) 2412.175522272 Cursor::SendResponseInternal > SendResponse 2412.175564290 BackgroundCursorChild::RecvResponse (+42us) Note one continue() invocation on Chrome is ~30us in average.

Maybe we can 1) prefetch, and 2) let the transaction thread pool to handle IPC directly.