Open krille-chan opened 1 year ago
Other suggestions added from internal meet:
Extremely desirable fix! Will it also fix, that the Fluffychat becomes laggy if the user have a lot of huge rooms (like Matrix HQ etc.)?
Also maybe "Room topic String" can be also added to the RoomListItemSummary (or if the "I would suggest that we make the RoomListItemSummary object expandable in a way that it contains a custom map for additional information and an API so that the SDK consumer can inject a dart function to react on sync to update this map." is implemented, it can be done with it)
This is a refactoring proposal about the Matrix Dart SDK to improve the start-up performance and memory usage of apps using the Matrix Dart SDK.
What is the current state?
On init the SDK loads all rooms from the store into memory. But also a lot of States which are needed to display a nice room list in the UI. This includes:
So on app start the SDK loads a lot of stuff from the store to display the room list:
And this needs some time and scales badly. Also this may need too much memory.
Ideas
Future<Type>
RoomListItemSummary
object:String
URI
String
DateTime
bool
bool
bool
(also triggered to be toggled like "hasNewMessages")This is then indeed duplicated in the database but it means that to start the app we only need to load all room objects from the rooms table of the database which should work much much faster.
This way we would include some logic on the one side but also can remove them on the other side. We wouldn't need other getters anymore which currently search inside of state events to calculate stuff for us.
If a specific app needs additional information, this could become tricky though. I would suggest that we make the
RoomListItemSummary
object expandable in a way that it contains a custom map for additional information and an API so that the SDK consumer can inject a dart function to react on sync to update this map. For example could the room type be an additional parameter which then updates by a dart functionality written by the SDK consumer.Pros
App would start much faster and consume less memory. The overall performance will probably drastically improve.
Cons
We would have some duplicated data where we always have the risk that the can become out of sync. More specific use cases like the need for the room type could become more complicated. Accessing other parameters always as a Future could also produce problems.