Is @concurrent now the standard tool for shifting expensive synchronous work off the main actor?

I think for the vast majority of iOS use-cases here people are overcomplicating things.

  1. Modern computing devices are unbelievably powerful. Have you verified that there’s actually a problem? “Just do it synchronously” works remarkably often, and “async but on the main actor” covers a surprisingly large chunk of the rest
  2. If there is a problem, have you used Instruments and related tools to profile and optimize the code? Fast is almost always superior to slow-but-async, for battery reasons among others
  3. Having verified that you really do need to be async: do you need to be parallel? Phones have had 6 cores for quite a while, occupying one of them for a bit is no big deal
  4. If you really do need to go 6-wide with long-running tasks, stick some yields in
  5. If you really need >6 long running uninterruptible tasks, is it actually better for your user experience to try to make partial progress on all of them rather than getting some finished?
  6. If you have >6 long-running uninterruptible tasks that are also latency-sensitive and can usefully make partial progress, a) your poor user’s battery, b) now you can finally start considering workarounds like using libdispatch to switch from cooperative to preemptive multitasking
  7. …but if you have unbounded N of them, you can’t use libdispatch to go wide either because you’ll hit the thread cap and things will start falling over. So you need specifically 7-63 tasks of this nature for this to be a viable approach.

Is this actually a situation a lot of y’all are in?

29 Likes