What if A was synced to AnkiWeb before B?
I feel like automatic optimization could be made optional, there are a lot of people who only use one device (I do) and some who use multiple but use only one for doing reviews. This can later become a base for an improved auto optimisation feature. And who knows, some user might volunteer to help with this (I hope).
1 Like
Doesnât matter. Only the time of modification matters.
From: Syncing with AnkiWeb - Anki Manual
If the same card has been reviewed in two different locations, both reviews will be marked in the revision history, and the card will be kept in the state it was when it was most recently answered.
1 Like
Idea: Automatic Optimisation will only happen when you have completed all your cards for the day. Then there will be accidental auto optimisation in a different device which doesnât have everything synced.
Limitations: There are people who set their new card limit to a number they donât really finish. I once saw someone with 99999 as the limit.
+People sometimes have inactive decks with new cards that they donât study.
1 Like
That reduces my concerns about sync conflicts if the cards are not changing, but thereâs still the slow optimization calculation that has to happen automatically. That calculation is not cheap in large collections, and we canât use something like âon open/closeâ, as we donât want to be blocking collection open/close for that long, and there arenât traditional open/close cycles on mobile devices. Depending on when the calculation happens, it could lead to duplicate work being done, or preset changes being clobbered if they werenât already in sync.
1 Like
To this, add:
If the memory states of the cards are not updated, the new memory states on the next review will be calculated from the ones before re-optimization. We can solve this problem by recalculating the memory state from the entire review history at each review, but that will be computationally expensive.
1 Like
Isnât that what happens already â whenever there is a manual re-optimization, but no reschedule?
I stand corrected! Thanks, @Expertium !
No.
and we canât use something like âon open/closeâ, as we donât want to be blocking collection open/close for that long, and there arenât traditional open/close cycles on mobile devices.
In AnkiDroid, that can be done similarly to how Auto-sync works, by running it in the background when the user leaves the app. If they reopen the app before it is finished, just continue the task in the foreground or cancel it.
So, this may be a problem in Apple devices, not all mobile devices.
I donât think it would be an issue. Some time ago, when FSRS was just being implemented, I looked at tests and found that the Rust implementation of FSRS takes 12.2 microseconds to process a card with 1 review. Thatâs twelve thousandths of a thousandth of a second.
Even with 1000 reviews, it only takes 9 milliseconds, or 0.009 seconds, to process them all.
Of course, the times are machine-specific, but unless you have an ancient PC from 2004, itâs fine.
The user is potentially switching back and forth between apps (think copy+paste to create cards). If the one month period elapses at an inconvenient time, the user may end up having to wait for the optimization to finish, or will need to repeatedly cancel it each time they switch back.
That benchmark ignores the I/O costs of reading that data from disk. If the userâs disk isnât able to respond to that request promptly, answering the card is going to block until it completes.
1 Like
The anki app assumes a convention that the person goes to bed at 4:00.
It is possible to determine that the automatic optimization occurs only at 4:00 or alternatively at another time chosen by the user.
Wouldnât that require a user to leave their device on overnight, with Anki running?
1 Like
The Windows desktop program uses idle hours for system updates.
I guess it is according to information that sometimes it happens that the computer stays on. beyond business hours.
In any case, I would not suggest leaving a computer on in optimization mode, it can be done with a single clickâŚ
In AnkiDroidâs auto sync, it is only triggered after completely leaving the app, not when the app is simply put in the background to switch to another one. And after deliberately closing the app completely, the odds of reopening it instantly arenât high.
From the more than 3 million users of AnkiDroid, how many complained of that after it being implemented months ago? Absolutely no one.
And no complaints is outstanding in an environment where you get people complaining about everything.
If the one month period elapses at an inconvenient time, the user may end up having to wait for the optimization to finish
Even in the scenario that this happens, is that a real nuisance? It only happens once a month, it takes only a few seconds, it only happens if the user deliberately set it, and if it is done in the background, it wouldnât be seen most of the times.
The sync dialog in Anki desktop when leaving the app, which could be done in the background, is way more annoying to me and yet Iâm not creating obstacles to that. Or the random backup âProcessingâŚâ dialogs that appear
1 Like
The sync dialog in Anki desktop when leaving the app, which could be done in the background,
If syncing takes a lot of time without any visual indicators, it will look like Anki stopped responding.
As for optimization, if collection is very large, it can take much more than 1-2 seconds. Though I still think that optimization in the background is a good idea.
If it is going to be like AnkiDroid, the process would happen after all the app windows are closed.
Maybe just leave a temporary icon in the system tray, or send a system notification (it is a thing I Windows, idk about other OSes) to sinalize that sync is running in the background. If sync takes long enough and the user re-open the app, just continue the process in the foreground, so it wonât look like the app doesnât respond
Idk how feasible is that with PyQt, but the idea stands.
And FWIW, this doesnât need to be background right now. An once a month dialog, opt-in, of just a few seconds is completely reasonable.
It would help if Damien could list the current blockers for the auto-optimization feature so we can find a middle ground
1 Like
Largely rehashing what has already been discussed:
- As @Expertium mentioned, it can take a lot longer than a few seconds on large collections.
- Depending on the timing of a sync before/after optimizing, you can end up optimizing on multiple machines, or undoing the optimization.
- Preset/card changes can also end up being reverted if user was not already in sync.
- How/when optimization should happen across the different platforms, given open/close is not practical, and the app may not be running all the time.
Thereâs a big backlog of other tasks that need doing. Given the fact that this is not some trivial change, I would rather we put this back on the back burner and focus on other things like getting the editor working in the mobile clients, getting more of the FSRS helper integrated into Anki, etc. first.
4 Likes
As @Expertium mentioned, it can take a lot longer than a few seconds on large collections.
Not a problem for a once a month AND opt-in feature.
How/when optimization should happen across the different platforms, given open/close is not practical, and the app may not be running all the time.
The person implementing this in Anki Desktop will handle that. I donât see any problems with AnkiDroid. Only you can know about AnkiMobile, but it shouldnt be a blocker to adding to the other platforms
Preset/card changes can also end up being reverted if user was not already in sync.
Depending on the timing of a sync before/after optimizing, you can end up optimizing on multiple machines, or undoing the optimization.
Canât they be reverted without automatic optimizations as well? Has that created any problem until now?
and focus on other things like getting the editor working in the mobile clients, getting more of the FSRS helper integrated into Anki, etc. first.
Everyone has different priorities. There are people very passionate about FSRS that may not care about the note editor. People who can think about the general algorithm and UX of this feature, but donât know how to code to help in the technical task of the note editor migration. Those people are willing to help for free, right now. They may not be here whenever those things are done, maybe years from now. So I encourage to take advantage of those people efforts and continue the discussion to at least unblock this, so a willing dev can eventually work on that.