Performance: avoid iterating over the full list of submissions

[pdpinch]

from @ormsbee:

I noticed in the SGA XBlock, at least two of the handler calls do full iterations over the entire list of submissions for that item (enter_grade and get_staff_grading_data). The "enter_grade" handler makes an average of 731 SQL calls, on an item with 185 submissions. It takes a little under 3 seconds to run, which will grow linearly with the number of submissions. This will at minimum make for a poor user experience, but could also endanger site stability on sufficiently large courses.

I'm not sure why it's doing this full iteration, but it doesn't seem necessary (particularly for the enter_grade case). I'd be happy to discuss any extensions the submissions API would need to meet your requirements.

An item with 200 submissions is a frustrating user experience. A course item with 2,000 submissions will probably start timing out the gunicorn workers entirely and causing us operational headaches.

[pdpinch]

• Performance: Stop getting all grades when calling enter_grades (and possibly other places too) #111 It looks like enter_grade has some potential optimizations, in particular removing the updating of all grades when we could just update the one that the user changed. This pattern appears in a few places. 4
• new issue get_staff_grading_data will be harder, as it necessarily needs to fetch the grades for everyone. Paging might help, but will require more research, probably into the submissions API. (for the future)