Application Performance and UX


I think we tried this library a while ago and it had some problems, though it was a year or something since then so maybe it is better now.

Also, I’m really not sure if this library actually switches threads in iOS, I only barely looked at the source code and I couldn’t find anything that creates an additional JS thread or switches to it.

I did profile the app and then the JS thread was indeed clogged and mostly because we had to process each message coming from a mailserver in JS. Theorizing about performance bottlenecks is a pretty unfruitful endeavour.

I think we have an option move down a level some of our code and just go multithreaded when we need that, since we have quite a lot of the logic already implemented there. If we just were a “pure” RN app, it would have make sense to look for a RN library for that. But we already have status-go and some API that we expose, so I think we should use that.


I’m curious to know what goes into processing a message and how long on average does that single operation take?


@igor I think there is still one problem with messages, because even though a lot of work was done in order to support batching them, it appears that currently there is still one event dispatched down the line for each message (:message/add event in ::chat-received-message/add-fx side effect). So if someone could look into that that might already be a big part of the clogging when fetching from mailserver

edit: I checked and they are received all at once so I was wrong


Prepared PR with subscriptions optimizations, and also some optimization to navigate between main tabs, main wallet screen optimized as well


Thank you @andrey that is awesome work that we should have done long time ago, kudos!

I have two threads opened to discuss implementation efforts to improve performances:

  • first one in regards to communication protocol in which I describe the steps to take before moving the whole thing to status-go (doing so without doing these steps first sounds like a very bad idea to me) , @igor is planning to look at first step next week. Performances: before moving communication protocol to status-go
  • second one is improving wallet perfs ans should take about a week, my plan is to look at react-side next week, go side is basically the same as for communication protocol. [Proposal] Fix the transactions list


One more picture from me, sorry
here you can see why wallet screen is slow, because we (1) request all tokens balances from a chain and (2) request prices from http api, each time we open wallet screen

(1) can be optimized by moving to status-go
(2) maybe we could cache it , and request prices only in some interval


@andrey this is already being discussed here [Proposal] Fix the transactions list