Read from CD/DVD Speed is VERY slow with enumeration/threading

Question

Having a bit of an issue with reading data from a CD/DVD. My program (using task.factory/threading) seems to otherwise be perfectly functional when reading from a local HDD. It's basically intended to enumerate through a bunch of image files to read information about those files and write it to a text file. Obviously reading from a CD is going to be much slower than most HDD etc. but it's ludicrously slow by comparison (more than 20x slower).

I'm wondering if this has something to do with the way the threaded program is trying to read the data on the disc drive and/or if there's anything I can do about it? Additionally, it very intermittently it seems to not be nearly as slow (but still much slower than reading from disk), if that's somehow a clue. Is it possible to fiddle with how the disk is being read or the read speed or... I don't even know. I don't think any more details of my program are necessary, but ask away if there's any additional information I can provide.

Answer 1

Disk IO is not something that parallelises well (except maybe on SSD) - and this is especially true on optical drives, which have low (compared to HDD - tiny compared to SSD) bandwidth, and pretty huge seek times. If you start seeking with multiple threads at once... yeah, that will be really slow.

Try to avoid having more than one thread accessing the disk. What you could do is have one thread to read data, which then pushes work into a work queue - and then as many workers as you need waiting to take work from the queue and process it. This will minimize IO contention, while still allowing the actual work to be processed in parallel.

Answer 2

Optical drives are CLV drives, Contant Linear Velocity. That makes them very good at packing lot of data on a disk. But that has one huge disadvantage, moving the read head to another track is very slow. It also requires changing the rotation speed of the disk. Not a problem when playing back a movie, big problem when you need random access.

Rule number one of disk drives with very slow seek times like that: never make the reader head move if you can avoid it.

Which invokes rule number two: never use more than one thread to read from such a drive. Since each thread will send the reader head to the track that it is reading from. Back-and-forth, the seeks make it very slow.

As in normal hard drives, there is no point in using more than one thread, they just take turns getting the drive to service their request. Threads can only buy you more cpu cycles on multi-core processors. So only ever use one thread to read.