The following article talks about the differences in QOS and M1 chips. With M1 we should be able to schedule tasks to ONLY run on the efficiency cores.
When you launch App Wrapper is currently runs a bunch of tests using a combination of a thread and shells to make these checks appear as transparent as possible.
I’d like to adapt this so that these only run on the efficiency cores, thus helping to make the application launch smoother, while using less energy.
Is this something that can be done with Xojo’s workers, could workers be adapted to adopt this, or do I have to write some Objective-C code and use GCD to get this? I’d prefer not to use Objective-C and GCD, because it adds a whole nother layer of complication to the project.
So what do you need?
Set a shell to a QOS class or a thread to a QOS class?
I’d suggest threads/shells should have an optional parameter - a priority (high / low) setting. One question is, what should the default be ?
I have some apps with non-urgent tasks that can (and should) run slowly in background at low priority, and yes there are others where I want all the CPU grunt available.
Somewhere down in its Unix bowels MacOS has a prioritisation for tasks (it was 0-10) maybe that should be considered too.
I don’t see any option in the Xojo Shell for launching console applications and specifying a QoS.
As for Xojo threads, they’re co-operative so it doesn’t really make any difference. In my case the thread has a low priority as it’s mainly used for scheduling, it is paused while a console application does it’s thing and then continues on completion.
Xojo Workers may want a QoS option so that workers can be run in the background “efficiently”.
I see that NSTask can have it’s QoS specified, I’ll consider replacing the Xojo shell with my NSTask classes.
Thanks for the suggestions Christian.
Some more info from Eclectic Light on utilizing efficiency cores with command line tools.
Some Apple information.
NSProcessInfo also has the ability to specify QoS when doing work, but I don’t know how that will work from a Xojo application, it may be that can be specified on launching a Worker, which will force a worker to use performance or efficient cores, I don’t know yet, and maybe redundant.
I think it’s definitely worth creating a feedback feature request for adding the QOS option to both Workers and Xojo shells.
We already have qualityOfService property in NSTaskMBS class in MBS Plugin.
I could maybe add more for other classes if needed.
I bet one of Sam’s purposes of having his set of NSTask classes is to not depend on a plugin, at least in this case
You probably know I already have the MBS plugin so why would I wait or make my own?
(and, for Sam’s classes, I respect the fact he may keep them for him)
I started this discussion because I wanted everyone to be able to participate, I am sure that there are things I missed or do not understand and quite rightly @Christian_Schmitz pointed out that I’d totally not seen the QoS property on NSTask, for which I’ve made already made a Xojo wrapper for.
I hope that Xojo add this option to their classes too, whatever they use under the hood.
With Sam’s classes, I mean the set of classes he offers as Ohanaware App Kit
p.s. Thank you @Christian_Schmitz for pointing me to NSTask’s QoS property.