kwindrem / SetupHelper

Helper functions to simplify writing setup scripts that modify VenusOs functionality. The package includes automatic reinstallation of the package after a VenusOs update.
151 stars 18 forks source link

General knowledge question #86

Open drtinaz opened 1 week ago

drtinaz commented 1 week ago

Hey Kevin this isn't really a setuphelper related question, but I don't know any other way to get in touch with you. I appreciate your knowledge and insight as I know you have a pretty good working knowledge of the gx platform. As you know I have been a major contributor to RemoteGPIO and am currently working on some further enhancements and trying to trim the fat and make the package run smoother. I have been able to cut the overall CPU usage by over 60% by removing some of the dynamic processes from the service and requiring a manual restart on configuration changes.

Long winded I know, but that brings me closer to my question. The driver CPU usage I have down to about 2%, but the overall CPU usage with all other processes that the driver uses (such as Dbus and settings) can be as high as 15-20% which can really tax a system with several components installed. Now to my question...when fetching settings, is there a difference in CPU/system resources when fetching from Dbus as opposed to fetching directly from /settings/RemoteGPIO? Is one method preferred over another? Anywhere else you think I might be able to reduce the system load?

I have started a discussion for enhancements on the RemoteGPIO GitHub if you would prefer to keep this off of your GitHub.

Thanks in advance for any insight you might have, it is very much appreciated.

Edit:Ok I'm an idiot. Going back and looking over the driver I see that settings are in fact pulled from Dbus. Don't know why I thought different. Please excuse my ignorance. My other question still stands however. Anything you can suggest to lower system resources usage?

kwindrem commented 1 week ago

Settings should have no more overhead than any other service on dbus. Settings do have a layer to make it's parameters non-volatile but would only slow down sets, not gets. The non-volatile update may be handled in a different thread so I'm not sure the sets are slowed either, but it does impact overall system performance. So any Settings parameter that gets set a lot should be filtered. The generator code has an example of this where the Settings values are updated only once every 10 or so seconds and a second parameter is kept in the generator service and updated more frequently.

One thing I did in PackageManager.py was to keep local copies of dbus parameters. A local variable access is much faster than making a GetValue call on a dbus parameter.

I didn't see your discussion on RemoteGPIO so if you have a link, I'll be glad to participate.

drtinaz commented 1 week ago

https://github.com/Lucifer06/RemoteGPIO/discussions/31