Improve Things overview performance

[wborn]

When my browser shows the Things overview (e.g. http://localhost:8080/#!/settings/things/) the performance isn't that great. As a result the browser is sluggish and scrolling isn't instantaneous.

It's probably because I have 100+ Things in this overview and it is processing 10+ SSE events per second because of this. I compared it with the Paper UI Things overview and it seems to handle the same amount of SSE events in its overview without any noticable performance issues.

Most of the messages are ThingStatus updates. It looks like there is no filtering done in the backend. So it pushes events to the frontend regardless of if there was any (status) change.

[ghys]

I'm not sure the problem is really with the SSE status updates (although 10+ a second is a lot!) but simply that the CSS of those lists is on the heavy side and perhaps suboptimal. Some channels lists with 200+ channels (Nibe pump simulator things) are affected too.

In my experience ~150-200 is the max number of items those lists can handle before you start to notice the performance degrading, depending on your device. After that using a so-called "virtual list" is recommended, but then you can say goodbye to that nice grouping by initial or binding (or channel group in the channels list case) because the items' height has to be fixed and predictable.

I used a virtual list for the items and in some other places, it was a non-brainer because most users will have hundreds if not thousands of items; but for things, rules and pages I was somewhat hoping that the vast majority would stay below that threshold.

Maybe we could transform to a virtual list but only after we reach such a threshold (you'll lose the grouping and the index on the right, but only in that case).

[wborn]

I just retested this by uninstalling all bindings so the frontend does not have to handle any SSE. When it doesn't handle any SSE there are no performance issues when scrolling through the list. I haven't looked at the code, but maybe the performance can be improved by only updating Things when there are actual changes.

[ghys]

Oh, okay, then it might be worth a shot 👍
Do you know why you have so many thing status updates, it really seems to be a lot? Maybe there's something to fix in the binding causing this?

[wborn]

I have many lights that are continuously polled for their state. That results in the ThingStatus updates. There's already some logic to reduce the number of updates to at most 1 per second per light, see eclipse-archived/smarthome#3816. It can probably be throttled even more, but it wasn't necessary previously because Paper UI had no issues with this amount of updates.

It would be nice if the backend was a little bit smarter and would only send SSE to subscribers for changes. That would be a more generic solution which would solve the issue for all add-ons and SSE subscribers.

[ghys]

@wborn could you do a bundle:update org.openhab.ui https://ci.openhab.org/view/Pull%20Request%20Builds/job/PR-openHAB-WebUI/lastSuccessfulBuild/artifact/bundles/org.openhab.ui/target/org.openhab.ui-3.0.0-SNAPSHOT.jar and tell if it helps with your performance problems?

[wborn]

Yes it helps a lot with the performance! It makes the scrolling fluid again.
I don't notice any lagging at all with these changes. Thanks for looking into this @ghys. 👍

[ghys]

Great, let's merge it then.