Does that mean that the execution of series of blocks on a serial queue is generally slower compared to execution of those blocks on a thread because (other differences aside) in the thread case the "memory barrier tax" can be avoided?
Yes, retargeting serial queues to a non-overcommit queue is a valid technique in some cases* for that reason. Ideally though you'd instead design your system to avoid hitting the lower non-overcommit thread count limit as well, because even 64 threads is probably more than you actually wanted. I'm personally fond of a minimalist "one queue (perhaps the main one) for fast operations, one queue for slow operations" approach, but I'm also more practiced in writing code that runs in system daemons, where any threads I create are competing with the foreground app.
*e.g. a system that creates an arbitrary number of objects, each of which have an internal serial queue, which they block loading data for the object from disk
1 Like
The Swift function
DispatchQueue.globalalways returns the non-overcommit queue.
Why @eskimo here advice do not use DispatchQueue.global().async, because global concurrent queue might overcommit?
I believe we’re using the term in slightly different ways, which is unfortunately confusing. There’s overcommitting in the sense of creating more threads than cores, and there’s overcommit in the sense of the flag that can be set on a queue that modifies its behavior to overcommit more aggressively and with a higher thread count cap.