Question loading gets faster

[Arthur-Milchior]

Showing the next question is an important part of using anki. On my computer, it may sometime takes a fraction of second; enough to be noticeable even if it does not stop me from using anki.

I did realize that there was one pretty easy thing to do to make it faster; pre loading the next card. So I added a variable which store the result of "_getCard". The only trouble being that during reset, the next card may well be the card displayed in the reviewer. That is not a problem when the computation is done after the review is done; since the card will be marked as reviewed/in learning. Since I want to precompute the result, the reviewer should warns the scheduler so that it does not put the current card nor its siblings in the queue.

If it's not merged, I'll make an add-on out of it. I would understand if the complexity added was not worth the small speed increase it offers. However, it feels more pleasant to me.
Note that @agentydragon told, which is probably true, that to be even more efficient, the HTML should be pre loaded in the reviewer. I may try do to it later. I've no experience with web preloading, but it would make a lot of sens. Given than a complaint about 2.1 is that it became slower, I guess that it would actually be a nice improvement.
(And if it's done in Anki, it'll be done in AnkiDroid too, and there, it will be an important improvement, because AnkiDroid is slow)

[agentydragon]

Have you tested that doing this change in AnkiDroid speeds up AnkiDroid? Because I wonder: if you use the same collection on both, how come it's not a big performance win on desktop but it is on Android?

(Maybe your phone hardware is much slower than your desktop. That might be one explanation)

Edit: ah I just realized the Rust probably only works on desktop for now. maybe we can put it into AnkiDroid as well some day soonish...

[agentydragon]

Also you mentioned not replacing all fields in one go but instead doing it field by field is the slow part. Maybe that could be optimized instead, by doing the replacements all in one go?

I think it would be more elegant at least - you wouldn't need to add code to the scheduler.

[Arthur-Milchior]

Tests works on my computer. Given the failing test, I assume the problem was related to running the test near the new day limit.

[Arthur-Milchior]

I did mention the way fields were replaced indeed, but what I also told you was that it was a problem with anki's python code. I've not looked at rust so I don't know whether it's still the algorithm use on Anki (and actually, I can'te easily figuer out where the code creating the question/answer is in the rust files).
Mike Hardy's mentionned the idea of using Anki's rust in AnkiDroid. That should be possible given that Anki's AGPL is compatible with AnkiDroid's GPL. However, it does not seem that anyone had the time to figure out how to actually do the binding between rust and java in the codebase. Maybe it's something extremly simple and we're sitting on the easiest performance boost that AnkiDroid could have. But I'm not sure that the best place to discuss of it.

But to quickly answer your question: database access is really slow on Android, and not so much on (my) computer. In particular if a background save is being done, (which may take multiple seconds because of the size of the configuration's json), the database is locked on Android and so the question can't be fetched.

[dae]

Regarding Rust in AnkiDroid, please see ankidroid/Anki-Android#5805

There are parts of Anki's code that could be made more efficient, but the main reason Anki 2.1 feels slower is because we had to switch to using WebEngine, and WebEngine widgets are a lot slower to create :-(

I'm afraid I'd prefer not to merge this PR at this time, as it does make the code a bit harder to reason about. There are more rendering improvements to come in future updates, and I think it makes sense to see how they work out before deciding to go down the pre-rendering path.