4 ms·
The background QoS is telling the system to optimize for both other more important work and battery life. Even if other cores are available the system may still
by xenadu02 5y ago
The background QoS is telling the system to optimize for both other more important work and battery life. Even if other cores are available the system may still choose to run that work on efficiency cores to reduce power consumption. This may also include throttling IO.
Work that should be completed if resources are available should be at utility. This is a good level if you aren't sure what level to pick.
Work the user is waiting on should be user-initiated.
Work required for interactivity (updating the screen, background drawing, etc) should be user-interactive.
Higher QoS work that blocks on lower QoS work can boost the priority of that work, including across process boundaries in some cases like XPC.
All of these details are subject to change; communicate your intent to the system with the proper QoS class for best results.
- jeffbee 5y ago> Work the user is waiting on should be user-initiated. You'd think so, but software updates are run by signaling some daemon, and its tasks run on E-cores, which means if you are trying to use Xcode and it wants to install something, you may be waiting a very long time.
- saagarjha 5y ago> Higher QoS work that blocks on lower QoS work can boost the priority of that work, including across process boundaries in some cases like XPC. When correctly implemented, the process you’re waiting on will have its priority boosted appropriately.
- jeffbee 5y agoIf the API is easy to use, then I assume Apple's own software would get it right, but they don't, so it probably is not.
- saagarjha 5y agoThe API is largely “don’t use semaphores and other blocking primitives”. But it turns out people really love writing synchronization on top of these so it’s a hard problem to solve.