There was a lot of FUD around the topic, with some engineers blanket-claiming that "well, macOS is bad at threads, so there's that". I didn't buy that explanation because I had seen macOS under serious load in other occasions and none of this nonsense happened in them.
And then, almost by chance, I stumbled upon this QoS system, did a few spot-checks, and found that the VPN daemon was misconfigured to run at a low class. Consequently, Bazel starved the VPN for those users and made everything misbehave. Adjusting that one parameter fixed everything.
If you are curious, I ended up writing some more on this here: https://jmmv.dev/2019/03/macos-threads-qos-and-bazel.html
I’d expect the system-provided services to be correctly configured by Apple in this regard.
@dang or @op can we get QoS added to the title?
https://github.com/swiftlang/swift-evolution/blob/main/propo...
This should be a user-controlled feature, with tasks identified and labeled by the OS.
Why would you expect users to manage threads, processors, and system resources themselves?
For foreground apps like electron actually this wouldn’t do anything because you generally want it to be foreground. However, various extensions probably should use a different QoS level because responsiveness is better (eg code indexing, builds, etc).
The incentive is a better user experience and a lot of times software engineers end up using the software they’re building so the self interest incentive exists. And developers also exist who view it as a craft and push themselves to write better software.
Regarding prioritization across multiple apps’ processes, you might be surprised by just how considerate iOS developers can be. They (we!) tend to obsess over user experience, and knowingly adjust QoS to fit the user’s best position vs the app’s best position, understanding that such a values-first approach to development raises overall product quality. (You can call that “alignment.”) After all, it is literally a single line of code.
For my primary project minimal.app, I use .userInteractive QoS extensively for collaboration and sync, and otherwise fall back to a more appropriate QoS. The point that I have internalized is that this most crucial process (sync/collaboration) is an order of magnitude or greater more important than any other process. Of course I will internally prioritize this key process, and such internal prioritization naturally bleeds into the greater ecosystem appropriately, benefitting the user. This QoS system is so well-designed that my self-interest (or rather, my obsession with making my app as useful as possible) aligns across other apps and their self-interests.
Setting a standard is helpful, but providing well-engineered mechanisms and monitoring to accelerate compliance is critical to achieving the intended overall effects (let's say, battery life).
There is a recent w3c proposal to add explicit support for QoS hints to web workers:
https://www.w3.org/2023/Talks/TPAC/breakouts/web-worker-qos/
If every app did this properly, the benefit is that when you really need absolute highest priority for a task, you might actually stand a chance of getting it if every other app isn't doing exactly the same thing. But tragedy of the commons and all that..