TagLib::String::null considered harmful
kde-dev at emailgoeshere.com
Fri Mar 7 20:01:03 CET 2008
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
More information about the taglib-devel