I use a fancy template to allow for atomic clozes of summary-like markdown-like documents. For this purpose, my notes can have quite a few clozes. Now we are sadly limited to 500 by anki itself, but even below this amount the browser slows down considerably, even with only a single note.
To reproduce:
Create a note with a few hundred lines of text and a few hundred clozes.
Open the browser.
The browser will be slow.
For a particularly egregious example, switch the toggle to card view, and try and sort by something.
Details: I assume this has something to do with the implementation of sorting/choice of sorting algorithm. This behavior would be at least kind of understandable if the delay were only sorting on a field of a card, but it also occurs when sorting on columns such as ‘due’, which should not be influenced by the amount of text. By point of contrast, before implementing this system, I had a bunch of individual notes adding up to around 35k notes/60k flashcards, and anki was never even remotely as slow as with 1 note and a few hundred clozes. It is important to note that the reviewer handles these cards just fine, as does AnkiDroid.
Platform: macOS 12.0.1 Monterey / MB Air M1 Anki: 2.1.49
I’m pretty sure this is undesired behavior, but since github issues for anki strongly encourages posting here, here I am.
NB: I am pretty sure I will get responses of the type ‘the way you are doing flashcards is wrong!’. However, it isn’t. My card template ensures that atomicity, the 20 rules, etc. are ensured even for large amounts of clozes by using custom syntax and a huge amount of typescript. (see SamuelSwartzberg/oboeru2 on github for more details if interested) And even if I was somehow doing something inadvisable, there is no reason to have anki slow down for displaying cards with 100+ clozes.
Qt is slow at displaying large amounts of text in the table. If you hide the sort field, question and answer columns, do the performance problems improve? If so, maybe the 2.1.52rc2-qt6 build in the beta testing section will perform better for you.
The more text you put in your sort field, the more work has to be done when sorting on it.
If you’re using an add-on that modifies the behaviour of the browser, the add-on may be to blame.
Hey, thanks for then answer! So, regarding your causes:
Last one first: This issue is reproducible on a new, no-addon profile (first thing I checked :P)
1: Indeed, hiding the question, answer and sort fields does fix the issue! (Which is nice! Everything beyond this point is to a certain extent not so important, though it of course would be nice to be able to use those columns, though I can also identify notes by tag, so it’s not too bad either) 2.1.52rc2 does work better even with sort field/question/answer visible, but is still pretty laggy when scrolling.
2: I mean, at face value, that of course makes sense. But (and I hope I’m not being stupid or an ass), why do you need to read the entire field to sort it? If that’s happening, runtime costs will of course be O(n*m) ≈ O(n^2). But shouldn’t it be possible to compare the field one char at a time, or at least to take a small slice, compare that, and get more if results are inconclusive? And for a single note, why does text in the sort field slow it down so much, given it will be the same for every single card (i.e., why run intra-note comparison at all?) Again, I hope I’m not being presumptuous, and this may be harder to solve than it seems, it’s just that from the outside this seems eminently solvable.
The sorting is done at the DB level. Sqlite is likely smart enough to stop comparing after the first differing character, but if the text is long enough that it requires storing in multiple DB pages, I would not be surprised if that added extra overhead.
The lagginess could possibly be improved by truncating the text prior to displaying it, which you could experiment with in an add-on using the browser_did_fetch_row hook.
Ah, I see. Testing it, it may not be down to sorting after all. After your comment, I did some testing by importing 400 arbitrary but insanely long strings as individual notes, which produced the same problems as with the cloze cards. Since hiding the text-containing fields seems to solve it, and since the problem is also very pronounced when scrolling, this gives some support to the idea that anki/qt is just struggling with fetching/rendering that much text. I haven’t looked at all into addon development yet (I know python, but don’t write it with any regularity), but this does seem like it would be a pretty low-hanging fruit to try my hands at. Thanks for your insight!
Everything beyond this point is to a certain extent not so important, though it of course would be nice to be able to use those columns, though I can also identify notes by tag, so it’s not too bad either) 2.1.52rc2 does work better even with sort field/question/answer visible, but is still pretty laggy when scrolling.