Long freeze when first messages load #10

New issue

Open

opened 2023-01-02 14:35:20 +01:00 by badrihippo · 1 comment

badrihippo commented

2023-01-02 14:35:20 +01:00

Owner

A solution would be to space out this "every message" reaction in the first minute or so: instead of "every message", it should set a clock or something that refreshes every, say, 5 seconds, and then switch to one second. That way, people can start scrolling without having to wait for all the messages to come in.

(The main problem here is that Svelte requires an = assignment to start working. But actually, that might not be a bad thing because if it automatically updated the display everytime any small thing got changed it would still/ result in a lot of overhead!)

When the first messages load, the app "freezes" for a long time. This is probably because it's set to update the messages array every time an event comes in, which, the first time you log in, would mean a lot of events! A solution would be to space out this "every message" reaction in the first minute or so: instead of "every message", it should set a clock or something that refreshes every, say, 5 seconds, and then switch to one second. That way, people can start scrolling without having to wait for all the messages to come in. (The main problem here is that Svelte requires an `=` assignment to start working. But actually, that might not be a bad thing because if it automatically updated the display everytime any small thing got changed it would still/ result in a lot of overhead!)

badrihippo added this to the Minimum working version project 2023-01-02 14:35:20 +01:00

badrihippo commented

2024-03-23 08:43:48 +01:00

Author

Owner

A stopgap measure has been implemented for this in 8d1ca787fa. Basically, we don't auto-join groupchats at all, because the large number of incoming messages from there was causing the app to freeze regardless of the auto-rendering.

Another optimisation, added in 15bfc1599b, replaces the rendering function with a lighter version that only includes the required data instead of the whole shebang. This will make the function more efficient, although it still doesn't address the fact that it may be called too many times.

But we should still implement the original proposal at some point, because the issue will remain when a user receives many private messages at once, or when the messages start coming in after they've manually joined a groupchat.

A stopgap measure has been implemented for this in 8d1ca787fa7e3a8f22e7d0bba616e8e9ab5f3b02. Basically, we don't auto-join groupchats at all, because the large number of incoming messages from there was causing the app to freeze regardless of the auto-rendering. Another optimisation, added in 15bfc1599b0e5b30c66ae9475865877d54e799b0, replaces the rendering function with a lighter version that only includes the required data instead of the whole shebang. This will make the function more efficient, although it still doesn't address the fact that it may be called too many times. But we should still implement the original proposal at some point, because the issue will remain when a user receives many private messages at once, or when the messages start coming in after they've manually joined a groupchat.

badrihippo referenced this issue from a commit

2024-03-23 09:28:07 +01:00

Keep 5-second delay between renders to withstand message floods