None of these are high priority, but we could make things snappier by:
paginating the find_studies call that fills the curator front page. It's getting pretty big (33M)
storing the output of otindex's find_studies and modifying it in memory as studies get edited. Obviously this would be more of a pain.
storing the find_collections output and modifying it in memory (as in 2, but for collections)
adding a without_version_history call for getting a study and then loading the version history of a study asynchronously through a separate call. Same total time (or worse) for the curator. But the history tab could lag. We are committed to adding the history by default at least in version 3 of the APIs, but it does add a fair amount of extra work for something that not all users want/need.
None of these are high priority, but we could make things snappier by:
find_studiescall that fills the curator front page. It's getting pretty big (33M)find_studiesand modifying it in memory as studies get edited. Obviously this would be more of a pain.find_collectionsoutput and modifying it in memory (as in 2, but for collections)without_version_historycall for getting a study and then loading the version history of a study asynchronously through a separate call. Same total time (or worse) for the curator. But the history tab could lag. We are committed to adding the history by default at least in version 3 of the APIs, but it does add a fair amount of extra work for something that not all users want/need.