[performance] Performance EPIC

[flexsurfer]

https://discuss.status.im/t/the-story-about-100ms/1630

General:

• Investigate reagent tick [perfromance] Investigate reagent tick #10378

Sign in:

• Improve sign in flow [perfromance] Improve sign in flow #10377

Chat:

• Optimize chat subscriptions [perfromance][chat] Optimize chat subscriptions #10379
  * [ ] Remove all subscriptions from list items [perfromance][chat] Remove all subscriptions from list items #10380
• Optimize input field in chat [perfromance][chat] Optimize input field in chat #10385
• Optimize chat view [perfromance][chat] Optimize chat view #10386
• Optimize navigation [perfromance][contact] Optimize navigation #10382

Contacts:

• Optimize contacts subscriptions [perfromance][contact] Optimize contacts subscriptions #10381

Part 2 (26/04/21)

So far we've implemented lots of improvements but why UI sometimes still slow and clunky?

First, lets separate UI slowness (unresponsiveness) and loading (UI is responsive)

For loading, we know the next issues

1. sign in takes long time (loading indicator, UI is responsive ) - its a known issue, if there is lots of contacts or chats it takes time to start a node

• If there is lots of contacts or chats it takes time to start a node  status-go#2215

2. status timeline first time opening (loading indicator, UI is responsive ) , same issue, fetching from sql slow when lots of contacts

UI slowness (unresponsiveness)

99% of time its js thread, here we have two major parts, 1 - re-frame event handlers , 2 - reagent/react , they go one after another, and we have T = Th + Tr , in ideal T should be less than 100ms

for Th most critical parts are signals, new messages, chats, mailserver filters etc, some of them might take even seconds.
for Tr most critical, screen creation and screen forceUpdates especially with flatlist, some of them might take even seconds

so in worst cases, it can be a signal which takes a few seconds and then screen update with flatlist which might take seconds as well, in that case, any buttons will be unresponsive, js task for button event handler can't be run because js thread is busy

known issues

1. most critical one, after sign in with lots of chats there is a tabs screen with loading indicator, but UI is unresponsive for a few seconds (not possible to navigate between tabs), here we have both Th and Tr, in Th we have lots of event handlers with app data initialization and for Tr we have flatlist with chats

2. opening chat, and messages scrolling, same here , Th for handle more message from status-go and Tr for flatlist creation/update

3. sometimes any part of UI can be slow because there is a signal from status go, and handlers use js thread for a long time, for example signal from mailserver is heavy

So there are two most critical directions

1) Flatlist

The most critical part is item renderer or item layout, it should be just flat and simple without any logic or complex layout, in our case for both chat and message items item is very complex

• We need to find a way how to improve item renderer

2) re-frame handlers

The most critical part is signals from status-go , app initialization and loading more messages in chat
We need to

• cover handlers by performance tests
• if possible move to status-go
• try RN multithreading
• optimize code

we already moved a lot to status-go its not a simple task, currently, we're moving mailservers , it should improve a lot

[cammellos]

Moving to discussion, and we can add each item when ready to be worked on