We were retrieving all the bookmarks to start the exercises, which for users with many bookmarks would cause waiting times to start exercises (up to 15 seconds!). This would happen every time they start exercises, and there is no need to load all the available bookmarks.
Instead, now the query only limits to the number of bookmarks requested by the frontend, and by default it's 100. This is used in the exercises, which can query up to 200 bookmarks, (100 scheduled and 100 unscheduled) which are then sorted and returned. This results in a reduction to about 1-2 seconds in my own server, which is OK for our purposes.
We still have an issue when users have many bookmarks and they go to the Words page, where all the bookmarks are loaded. In this case, maybe we could use pagination or something along those lines?
github-actions[bot]
commented
4 weeks ago 
We were retrieving all the bookmarks to start the exercises, which for users with many bookmarks would cause waiting times to start exercises (up to 15 seconds!). This would happen every time they start exercises, and there is no need to load all the available bookmarks.
Instead, now the query only limits to the number of bookmarks requested by the frontend, and by default it's 100. This is used in the exercises, which can query up to 200 bookmarks, (100 scheduled and 100 unscheduled) which are then sorted and returned. This results in a reduction to about 1-2 seconds in my own server, which is OK for our purposes.
We still have an issue when users have many bookmarks and they go to the Words page, where all the bookmarks are loaded. In this case, maybe we could use pagination or something along those lines?
Running times:
(Same user, goes to exercises)
Before:
all_bookmarks_priority_to_study took: 14.7286 seconds, total: 1802After:
all_bookmarks_priority_to_study took: 1.7743 seconds, total: 131