Speed up deck list by rendering it with the backend #11599
Closed
Conversation
This file contains 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
Pass it in to processChildren() instead, which is cleaner, and will work better with the move to a backend method.
Currently limited to V1 due to changes in 2.1.41
This requires david-allison/anki#2 to be merged into a new AnkiDroid backend release before this can be used.
The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future.
|
Once AnkiDroid has moved to V16, the old Java code can be cut: 5fa2b05 |
|
Dependent work to integrate the required change in Anki-Android-Backend tracked here ankidroid/Anki-Android-Backend#200 |
This was referenced Jun 11, 2022
|
@dae meta comment - thanks a bunch for all the little fixes in here by the way going to do my best to unblock / merge / release all this stuff so any of your time spent is productive as we can obviously really use the extra set of hands in the area |
mikehardy
added a commit
to mikehardy/Anki-Android
that referenced
this pull request
Jun 12, 2022
This moves closer to unblocking ankidroid#11599
7 tasks
mikehardy
added
the
Blocked by dependency
mikehardy
added a commit
that referenced
this pull request
Jun 12, 2022
This moves closer to unblocking #11599
|
This should be rebased, I managed to bull through cherry-picking the patch in a merge-able spot, and figuring out how to publish the backend, and integrated it here #11605 - so now depends on the other PRs but not any other deep infra does it really depend on those other two PRs? I'm not sure based on my read of those how this one would depend but maybe I'm being dense, seems they are orthogonal in intent? Or does this actually depend on V16 somehow (which seems more than those other 2 PRs do...) |
|
If #11581 is not merged, I think the build will fail as the abstract method is not implemented in the Java backend. The tests are not a hard requirement, but having 0 failing tests makes it easier to see that this PR hasn't introduced failing ones :-) |
|
Ok - I understand the dependency now I think, obvious in hind sight. 2 paths then: 1- low effort / longer time path: leave as is + blocked by dependency on java backend drop PR while I get acrarium (new crash report system) setup and we get a sample to base dropping the backend on just to make sure, probably a week, but deadlines are open source poison so could be who knows I think 1 is fine, I'm not pushing for 2 just saying how it will go since this will sit for a bit then optimizing for fewer comments vs having this on the right thread I'll say I'm still confused on the V16 test PR, as I had literally zero success with it in "testing v16 mode", I just don't know how you got that one to pass. |
|
No big rush on my end - I've fallen down the rabbit hole of looking into what's involved with updating AnkiDroidBackend to the latest desktop code, which is why I haven't had a chance to try repro the issue you reported yet. If it's easy, could I trouble you to get Kotlin working on the backend repo? I tried following some instructions online to add the deps/classpath to the build.gradle files, but was still seeing missing symbol errors when I tried converting one of the files to kotlin (from the java files that were trying to access it). |
|
Nevermind, I think I'm close to getting it working now. |
|
I just got our crash report database up so we're back to 💯 after the server compromise, so I can circle back around and focus more on this again in the next couple days myself |
thedroiddiv
pushed a commit
to thedroiddiv/Anki-Android
that referenced
this pull request
Jun 14, 2022
This moves closer to unblocking ankidroid#11599
dae
added a commit
to ankitects/Anki-Android
that referenced
this pull request
Jun 20, 2022
This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from ankidroid#11599
|
I've merged this into #11644 |
dae
added a commit
to ankitects/Anki-Android
that referenced
this pull request
Jun 21, 2022
This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from ankidroid#11599
dae
added a commit
to ankitects/Anki-Android
that referenced
this pull request
Jun 25, 2022
This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from ankidroid#11599
dae
added a commit
to ankitects/Anki-Android
that referenced
this pull request
Jun 25, 2022
This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from ankidroid#11599
dae
added a commit
to ankitects/Anki-Android
that referenced
this pull request
Jun 28, 2022
This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from ankidroid#11599
dae
added a commit
to ankitects/Anki-Android
that referenced
this pull request
Jun 28, 2022
This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from ankidroid#11599
dae
added a commit
to ankitects/Anki-Android
that referenced
this pull request
Jun 28, 2022
This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from ankidroid#11599
mikehardy
pushed a commit
that referenced
this pull request
Jun 29, 2022
This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from #11599
mikehardy
pushed a commit
that referenced
this pull request
Jun 29, 2022
Pass it in to processChildren() instead, which is cleaner, and will work better with the move to a backend method. Speed up deck list by rendering it with the backend This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from #11599
mikehardy
pushed a commit
that referenced
this pull request
Jun 29, 2022
Pass it in to processChildren() instead, which is cleaner, and will work better with the move to a backend method. Speed up deck list by rendering it with the backend This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from #11599
mikehardy
pushed a commit
that referenced
this pull request
Jun 29, 2022
Pass it in to processChildren() instead, which is cleaner, and will work better with the move to a backend method. Speed up deck list by rendering it with the backend This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from #11599
mikehardy
pushed a commit
that referenced
this pull request
Jun 29, 2022
This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from #11599
mikehardy
pushed a commit
that referenced
this pull request
Jun 29, 2022
Pass it in to processChildren() instead, which is cleaner, and will work better with the move to a backend method. Speed up deck list by rendering it with the backend This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from #11599
mikehardy
pushed a commit
to ankitects/Anki-Android
that referenced
this pull request
Jun 29, 2022
Pass it in to processChildren() instead, which is cleaner, and will work better with the move to a backend method. Speed up deck list by rendering it with the backend This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from ankidroid#11599
mikehardy
pushed a commit
to ankitects/Anki-Android
that referenced
this pull request
Jun 29, 2022
Pass it in to processChildren() instead, which is cleaner, and will work better with the move to a backend method. Speed up deck list by rendering it with the backend This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from ankidroid#11599
mikehardy
pushed a commit
that referenced
this pull request
Jun 29, 2022
Pass it in to processChildren() instead, which is cleaner, and will work better with the move to a backend method. Speed up deck list by rendering it with the backend This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from #11599
dorrin-sot
pushed a commit
to dorrin-sot/Anki-Android
that referenced
this pull request
Jul 14, 2022
This moves closer to unblocking ankidroid#11599
dorrin-sot
pushed a commit
to dorrin-sot/Anki-Android
that referenced
this pull request
Jul 14, 2022
Pass it in to processChildren() instead, which is cleaner, and will work better with the move to a backend method. Speed up deck list by rendering it with the backend This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from ankidroid#11599
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code.
Depends on the following PRs in this repo:
#11579
#11581
And on a new backend release from David, after merging
ankidroid/anki#1