(#6068) - safely re-implement IDB docCount optimization #6070
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
Author
|
Legit failure in Android 5, Chromium 37. I will investigate |
nolanlawson
force-pushed
the
6068
branch
2 times, most recently
from
f412ecd to
349f7d2
Compare
Member
Author
|
Failures are still genuine in Android. This needs work. |
Member
Author
|
Green! |
daleharvey
approved these changes
Jan 2, 2017
Contributor
daleharvey
left a comment
daleharvey
left a comment
There was a problem hiding this comment.
These changes look good to me, thanks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This re-implements the docCount optimization for IDB, but this time doing it in-database rather than in-memory, so it actually works across tabs/workers.
I rebased this on #6060 (which itself was rebased on #6056) because I really wanted to avoid bitrot. Sorry for the confusion.
The implementation is essentially do the same thing we were doing before, but instead of caching the
docCountin-memory, we cache it in theMETA_STORE. It's always re-calculated when the database is initialized, and then after that the cached value is used duringallDocs(), and updated based on a delta calculation system inbulkDocs().I measured the perf gain using FF50, Chrome 55, and Edge 14 (2013 MBA, Edge running in Parallels). The test was
all-docs-startkey-endkeyfrom #6067, bumped up to 50 iterations for better accuracy. I measured only the difference between #6060 and this PR:So it's a mild perf regression for Firefox, but a huge win for Chrome and Edge. And given that Firefox is already faster than Chrome, I think this is a huge improvement.