Very slow redrawing of window after ~1 day

[Civil]

Hi!

If I leave quassel-webserver connected to quassel for approx. 1d, then it becomes very slow - I mean switching to other channels takes tens of seconds to actually perform the switch. Also I've noticed high CPU usage of quassel-webserver tab.

Browser: Chrome 45 on MacOS 10.10.

[Civil]

Just some notes - I've got less then 1000 messages in a backlog when I'm starting to feel performance issues. And for some bigger chats backlog can contain 2-3k messages.

[magne4000]

Sadly I'm aware of this, but the combination of the aging quassel protocol + the fact that everything is handle client side in Javascript (especially with AngularJS) make it really difficult to optimize 😐

[Gnarfoz]

Mh. Good thing I searched before opening a new ticket on this. :(
This happens to me after as little as 3 hours or so. Channel switching becomes unbearably slow.
Reloading the page and logging back in makes it all snazzy again.

[magne4000]

That's a difficult problem, but here are the options we have (feel free to participate):

1. Optimize existing code - but I think that I already optimized all huge parts of the application. Also, there does not seem to be any (noticeable) memory leak (or proove me wrong 😃).
2. Use a Web Worker for libquassel, this should be feasable and should benefit in term of performance. Main optimization axis
3. Use Indexed Database API to lighten the memory impact. That could tweak performance with the combination of Web Workers, or this could just slow everything down.

Point 3. would take an enormous amount of time for an incertain outcome, so I think it's not worth digging into.
Point 2. is the best thing to try for now, but requires a huge amount of time on it's own, so no promises on a delay for a POC, but I'll definitely try this it.

Anyway, I'm reopening the ticket, someone might have another idea or would want to help.

[tecknojock]

Uhh what about trimming backlog of unfocused buffers? And then just forcing having to re retrieve them if the user decides to scroll back up that much? I know I wouldnt miss having more than 200 lines reloaded when I come back to a buffer. You could make it a selectible length, and perhaps the option to only purge read lines.

[magne4000]

That's would be a nice workaround, I would just have to make sure that this is configurable and can be deactivated (and off by default).

[magne4000]

@Gnarfoz Was it slow also when switching to buffer with a small amount of backlogs ?

[tecknojock]

For me its only slow when I'm swapping to a buffer with a large amount of backlog. Smaller less active channels are always snappy.

[magne4000]

In fact point 2. will not help, what takes most of the time is angular ng-repeat with the combination of ng-sanitize. But last commit (df41083) really improves redraw performance nevertheless.

[Gnarfoz]

Just to add my two cents: same here, small buffers are fast, bigger ones are slow as molasses and block the whole UI for a long time (I don't think there's a limit, tbh).
Took a while to confirm, Chrome just kept dying on me. 💣

[magne4000]

I tried some optimizations but without success, 0dec1a2 and df41083 will certainly be the only 2 commits regarding this issue (It's at least much faster than before, but not as fast as I wanted). The next step would be to replace angular by something else ... So not for now :)

[tecknojock]

For the empty buffers on switching, could we have that set to not empty it entirely? But like trim down to a certain number, like say 100 messages or so. It'd save a little bit of reloading.

[magne4000]

I added the possibility to choose how many messages you want to keep (from 0 to 999)

[tecknojock]

Hmmm I'm not sure that the choosing how many messages to keep is actually working properly. Despite setting it to 200 it seems to clear everything anyways. I still get a fetching backlog message.