[takoi]

And while 0.3% CPU per thread isn't a great deal, when there are multiple LanguageInvoker threads all using 0.3% CPU its an amount that adds up on low powered devices. Sure, even 1-2% of wasted CPU isn't a great deal, but it's 1-2% (or more, depending on the number of addons) that doesn't need to be wasted if there existed a "better" xbmc.sleep() mechanism. Of course, getting developers to adopt the new, improved sleep mechanism is likely to be an uphill struggle assuming addon code changes are necessary.

The reason I've been looking into this is because I wanted to write yet another addon that would end up sleeping most of the time, but I've decided against writing it rather than add to the ever growing list of addons that waste CPU time while "sleeping".

Wow. are you serious? All this fuzz for 0.3%, by the way these 'percent cpu usage' tests have why higher margin of error than that. Also, if you'd look at the implementation of xbmc.sleep you'd see it sleeps in 100ms intervals regardless. Talk about premature optimization.

[Milhouse]

Wow. are you serious? All this fuzz for 0.3%, by the way these 'percent cpu usage' tests have why higher margin of error than that. Also, if you'd look at the implementation of xbmc.sleep you'd see it sleeps in 100ms intervals regardless. Talk about premature optimization.

Well yes, I am actually, because I don't like to see inefficiency that can be avoided/eliminated, and in this particular case it's an unbounded inefficiency - the more addons a user installs, the more system wide inefficiency there is. So many addons don't need to sleep/wake at all, so offering an alternative "pattern" for those that just want to monitor events/notifications would seem sensible.

Of course I realise these savings are quite small when considered individually, but on some systems every optimisation can help.

[KenV99]

I apologize if this seems like a hijack, but I thought the participants in this thread might be able to share some thoughts on this.

I also find it difficult to debug routines that need to run once the abort has been requested due to the five second rule. If I am using the debugger (I use Pycharm which uses the Pydevd debugger) and set a breakpoint in anything post abortrequested, the script is terminated while I am in the debugger. Is there anyway to programmatically extend this time?

If not, I'd like to suggest that be a setting in the advancedsettings.xml... If I was more adept at cpp, I'd give it a go myself, but I know my own limitations.