I think using Task() for I/O work like this is probably a mistake. Ah, my mistake. I should’ve clarified that this would all be running inside a single actor, so the resulting behavior should be equivalent to an NSOperationQueue with a width of 1. OK. SO, FYI, I did some very rough performance testing with the code I posted yesterday, and a queue width of 4 was ~4x faster than #1. However, the big question here is the nature of the data you're expecting to process. While we generally talk about it as I/O bound (and it technically is), I think that term can be somewhat misleading, particularly when you're talking about the devices’ local storage or other fast SSDs. The issue here is that, in practice, much of the volume’s catalog data is either already in memory or WILL be streamed into memory fairly quickly as you start iterating over the device. That means that in many cases, the real bottleneck isn't disk I/O but is actually how fast you can make syscalls into the kernel. Using multiple threads let
Topic:
App & System Services
SubTopic:
Processes & Concurrency
Tags: