[Bug] App runs slow when a thread has more than ~15 replies

[setch-l]

Steps to reproduce

1. Open the app on phone
2. Navigate to a post with a lot of likes / reposts
3. Open the thread view Issue: The app stutters and is hard to scroll.

Look at any note by Rabble or Jack for example.

[joshuatbrown]

Is #783 our solution for this?

[mplorentz]

@joshuatbrown I'm not sure yet. Still making sure I understand what the performance issues are. At this point I think sorting events in memory is the slowest part in which case I might go for a model refactor before paginating.

[mplorentz]

Here are my findings so far.

• Using note1d0f6l4jzt2wg2e8efcsll4pn8lc2qs85yselradp4m6k44dq22ws0ggvru to test.
• I found a quick fix that to improves scroll performance a lot after events have stopped streaming in (#1126). Now the initial load of the thread is the worst part.
• Question: how much of the initial load is event processing (helped by pagination) and how much is sorting (helped by model refactor)?
• Why does the order of the events in the UI change as things load? Sorting is by received time to avoid this, something seems broken.
• Noticed that processing contact list events can take up to 2 seconds for a single event. How much is this affecting main thread performance?
• Performance testing is complicated by the presence of #1112 and other Xcode issues, making gathering data a slow painful process. maybe I should do #1112 before this one.
• Fresh accounts that don't follow a lot of people (subjectively) seem to have better thread performance. Investigate.

[mplorentz]

It sounds like we are ok with the performance of threads after the improvements made for #1112. My recommendations for further improving thread performance are to change the design of the thread view so that we could paginate replies, to look into NIPs for getting the count of likes and reposts instead of downloading all the events, and the optimizations for event parsing I described here.