All the audio files (~50,000 of them) are stored on a fast Win 7 server on an SSD. Gigabit Ethernet, Intel NICs, tuned for low latency and small transactions. The network will transfer large files all day long at >120MB/sec.
The problem: Reading the whole file list takes 24 seconds using Mp3tag installed on the server. Right. 50,000 tags in 24 seconds. Pretty good, right?
Now, the same operation on a similarly powerful machine on the network takes just over 3 minutes. Clearly, it's network limitations and overhead, though a monitor on the network shows nothing approaching saturation. Latency is about 7 msec, according to Resource Monitor.
It would be really nice to speed this up. It would be nice for network situations like this, and for libraries on HDDs too, I suspect.
What I think would help a whole lot would be something like multiple simultaneous read channels (for the lack of a better term). I think (but admittedly am not sure), that Mp3tag reads one file at a time. That's what makes it slow. Modern HDDs on SATA connections using AHCI can support queue depths much greater than 1 and command queueing. So issuing multiple concurrent Reads would conceivably take advantage of that. Similarly, multiple Reads would go a long way to overcoming network latency.
I'm no developer, so I may be somewhat off-base, but just maybe this is an idea worth exploring. If my suspicions are correct, most typical users with HDDs would see some benefit, and anyone accessing a library over a network would probably find relatively huge decreases in startup time.
How about it?