Skip to main content
Software Engineering

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

5
  • "I do not expect any gain from using multiple threads for reading the file", well that is what I thought first, until I found the 9 year old Dr. Dobbs article I linked to. Commented May 10, 2018 at 17:14
  • 1
    I agree he should just just try. Still my money would be on the one read thread considering sustained sequential reads (which we are dealing with here) will always be so much faster than anything else. Note the test in the Dobbs article was performed with a RAID5 system with 4 disks, not exactly standard equipment for the average developer. Commented May 10, 2018 at 17:32
  • The thing I kind of threaten is "limiting" queue size. I not quite can imagine such of reading the file in chunks and tracking the queue size. Would it be like a tirvial while (file_not_ended && queue_size_is_OK)? Seems like not, coz then such a while would be terminated after the very first case when queue is full... any quick ideas? Commented May 10, 2018 at 18:56
  • The Raid5 system was only one of three disks in that test, and storage hardware has developed a little bit in between. And I guess it is not so important which equipment the OP uses on their developer machine, but what is used in their production environment. Commented May 10, 2018 at 18:57
  • @Sereja Read thread gets 1MB. Then takes 10 ms naps until (queueSize < max). Then enqueues 1MB. Repeat. Commented May 10, 2018 at 19:49