First of all I must say this UI is awesome. It is so easy to customize it.
But on my old Nexus 7 tablet I saw high cpu usage. So I researched a bit.
I submitted my first result to github. I was able to reduce the $digest cycles massive to now 1-3. Maybe this is a start for some optimizations, but at the moment this is only a draft.
I disabled the clock for this demo because it causes a full refresh every second.
My openHAB environment has many items with regular updates. This will run the openHAB service very often (about 500-1000ms).
I think it can be a problem with the “template widget”, if the user does not store the items in the settings. In this case we do not know which items are used.
But we could add a checkbox in the settings to that allows the widget to get all change events.
When an item is updated, its name is sent with the 'openhab-update' event as a parameter.
Since most widgets subscribe to updates for a particular item using OHService.onUpdate, this function should definitely be changed so it only calls the callback function if the item being updated matches (if no item is provided, then it should call it no matter what).
The template widget is different since it accesses $rootScope.items directly - but it could indeed watch for any update and recompile the template manually every time.
I have now added a optimized "Template Widget"version to my fork. If the custom widget uses items in the settings the widget only listen for these items.
is there any plan to create a pull request to merge it back?
I’m currently in the same situation. I have a openhab system with ~600 items, but only ~10-20 of them are updatet every minute.
My Tablet is running with constant 30% CPU. A further side effect is that there is a noticeable delay between user interactions and my guess is that is related to each other.
I think @ysc should say if this kind of modification has a change for a pull request. Maybe the direction is wrong, I’m not an Angular expert. I’ve checked the changes and they are still compatible with the lastest version.
At this point I think everything causing potential breakages has to be properly tested for regressions before it can be merged - the vast majority of users is fine the way it is, and not ensuring reliable updates to fix performance would be imho worse.
That being said, your approach makes sense @csowada, I’m not against altering the digest cycle and calling $digest directly in widgets, but I believe it should be behind some global switch like “enable partial updates (experimental)” that only affected users would have to turn on. Otherwise I feel better simply calling $apply when an update occurs so we’re sure everything is updated.
@holger_hees 10-20 updates a minute is not that much, but probably you have a lot of complex template widgets. Maybe there’s an obvious bottleneck that is causing the majority of your problems - profiling with Chrome’s performance tool (tutorial: https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/) could isolate it. I let it run as a test and apparently the slider is the main bottleneck in my particular case, maybe you would find something too: