TagLib::String::null considered harmful

[Jeff Mitchell]

Peter Hartley wrote:
> Yes, I benchmarked it. Following an "echo 3 > /proc/sys/vm/drop_caches"
> each time, a scan of a large corpus of FLAC files takes 818s elapsed
> single-threaded, 788s elapsed with 2 threads, 730s elapsed with 16, and
> 687s elapsed with 64 -- that's 16%, or over two minutes, quicker. This
> is on a relatively feeble CPU (600MHz VIA C3) with single local UDMA/133
> disk, Linux 2.6.24.
>
> What I suspect is going on, is that the workload is completely
> seek-bound. (Even with 64 threads going, the CPU spends >90% of its time
> in disk wait.) Having 64 outstanding requests at any one time probably
> lets the elevator sorting do its job and cause the average seek to be
> shorter, and therefore quicker. A SATA and/or RAID system would probably
> see even larger speed-ups.
>   

I wonder what the average various wait times were for each thread.  
Having multiple outstanding requests could let the elevator sorting make 
things more efficient in terms of disk access but you could pay a price 
in that some threads could wait a while for their request to come back.

That being said, I don't see why you'd have results like this unless 
your filesystem was fairly heavily fragmented, or depending on the 
filesystem's algorithm for laying out files in blocks.  In the case of a 
fragmented filesystem or a (in this case) bad algorithm, the disk reads 
in the single-threaded case would cause the disk to jump around, and the 
multi-threaded case could let the elevator algorithm do its work, as you 
saw.

--Jeff