| commit | b0342fe3abb6b4f238589227cfd5f2cb619799e0 | |
| author | jsbell@chromium.org <jsbell@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | |
| Wed, 11 Sep 2013 00:09:33 +0000 (11 00:09 +0000) | ||
| committer | jsbell@chromium.org <jsbell@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | |
| Wed, 11 Sep 2013 00:09:33 +0000 (11 00:09 +0000) | ||
| tree | e1b4c747b75843a2d377a285c29295d3dd8185e8 | treesnapshot (tar.gz zip) |
| parent | 6bab2e3fa749bd3b328c5814ece101f49f420911 | commitdiff |
IndexedDB: Remove O(n^2) algorithm from transaction coordinator
While looking at crbug.com/280741 I found that we were scanning over
all earlier transactions for each queued transaction to determine
if it was blocked/unblocked. This would impact that bug by reporting
a transaction as blocked on a running transaction, even if it was
queued behind another blocked transaction.
This CL just eliminates the O(n^2) behavior by building up a set
of locked stores as the queue is scanned.
R=alecflett@chromium.org,dgrogan@chromium.org
BUG=280741
Review URL: https://chromiumcodereview.appspot.com/23889011
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222412 0039d316-1c4b-4281-b951-d872f2087c98
While looking at crbug.com/280741 I found that we were scanning over
all earlier transactions for each queued transaction to determine
if it was blocked/unblocked. This would impact that bug by reporting
a transaction as blocked on a running transaction, even if it was
queued behind another blocked transaction.
This CL just eliminates the O(n^2) behavior by building up a set
of locked stores as the queue is scanned.
R=alecflett@chromium.org,dgrogan@chromium.org
BUG=280741
Review URL: https://chromiumcodereview.appspot.com/23889011
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@222412 0039d316-1c4b-4281-b951-d872f2087c98
| content/browser/indexed_db/indexed_db_transaction_coordinator.cc | diffblobblamehistory | |
| content/browser/indexed_db/indexed_db_transaction_coordinator.h | diffblobblamehistory |