freedomofpress
improve performance for many submissions per source
On first start of the client, we add widgets for each item in the conversation view when we click on the source for the first time. If there are thousands of messages/files/replies per source, there will be a delay / the UI will be blocked as found with the SourceList in #846.
We should implement a similar fix as https://github.com/freedomofpress/securedrop-client/pull/944 to improve performance when adding widgets to the ConversationView.
For the 4/2-4/15 sprint, we'll aim to at least test in the "100 widgets per source" range, maybe with different combinations of messages/replies/documents. Would be good to have an agreed upon process for generating and using this dataset in a dev or staging env, per ongoing discussion in https://github.com/freedomofpress/securedrop/issues/5186
Per https://github.com/freedomofpress/securedrop-client/pull/1049#issuecomment-651402561 the client seems to be responsive in scenarios of up to a thousand or so messages/replies/submissions. This may not be a useful target for further optimization unless/until we see evidence that even larger source collections plausibly occur in the real world.
started a wiki page to track scalability and performance requirements and test results (it'll need more attention when we make time for this in the future :crystal_ball:): https://github.com/freedomofpress/securedrop-client/wiki/Scalability-&-Performance
Closing; we're rewriting the sync logic for the client rewrite (see https://github.com/freedomofpress/securedrop/pull/7604 and links) and are not currently planning to backport that change to the old client. We may still tackle some GUI performance improvements (see #1476) once we've landed on an implementation in the rewrite we're happy with. Keeping #1476 open as the issue with the clearest STR for the current client.