Howdy guys. Sorry for the crosspost. Patch to speed up taglib.

Jeff Mitchell kde-dev at
Fri Oct 12 04:28:11 CEST 2007

Speaking as an Amarok guy, I'm all for anything that gets rid of cache 
thrashing and makes computers (slower or not) usable.  I don't see much of a 
problem myself, but my collection is on a network drive over a wireless 

I'm not entirely sure what's happening for 2.0 yet.  I've heard rumors of 
Xesam interface to Strigi, with Strigi reading all the information (which may 
or may not be using taglib...I dunno even if there is an MP3 parser for 
Strigi yet, although I wouldn't be surprised).

The reason I bring this up is because I'm not sure how relevant such a patch 
would be for Amarok 2.0 (which I assume will still make heavy use of taglib 
for collection scanning, but maybe indirectly through Strigi, in which case 
this patch may only help if Strigi can actually scan fast enough to take 
advantage of it).  And no distro that I know of is going to make a taglib 
snapshot with such a patch that would be used for Amarok 1.4.x.  Despite our 
strong advice, half of them seem to still be using the official 1.4 tarball.  
So it may be worth looking into Strigi, Xesam, and the like -- after all, 
since Strigi will be integrated into KDE4 while Amarok 2.0 will not, if it 
will be doing MP3 scanning you may have an even larger target audience.

A few other comments:

1) You have a couple comments in there asking about compile time options.  You 
can use #ifdef and #endif statements for that, but how you specify those 
defines depends on the build system...another KDE3/KDE4 difference.

2) I can't help but wonder if perhaps a better idea would be to implement it 
as a separate API call, which basically calls these functions and then calls 
the original function.  That way the application could specify the 
appropriate method depending on what it's doing, instead of trying to 
hard-code it at compile time one way or the other.

Thanks for the kind words for Amarok on your post, and glad for the 


On Saturday 06 October 2007, Manuel Amador (Rudd-O) wrote:
> Well, that's the point -- even better then!  What are the chances that you
> need one of the 16000 files that thrashed the cache after a collection
> scan? Nothing should be cached by the OS until the file is actually going
> to be played, and unless there is heavy I/O or the caches are thrashed, the
> decoder isn't going to take more than 10 ms to fill the read buffer.
> The patch is probably going to help collection scan speeds a bit, but the
> most noticeable effect will be that slow computers will actually be
> *usable* *during and after* collection scans, because there will be less
> disk I/O, working set and cache thrashing during and after the scan.
> That's why the DONTNEED hint is there -- to tell Linux (and other
> POSIX-compatible OSes) that the file TagLib is reading will not be required
> to be held in cache because it is extremely unlikely that it'll be played
> right after scanning it.  And if the decoder thread actually falls into
> that unlikelihood, it will still be cached and readahead regularly because
> a SEPARATE fd will be opened to fetch data from the file.
> We're no better off discussing this subject until the patch has been tested
> by someone, and the test should be done with an unprimed cache first
> (there's a knob in proc to do that).  I'd volunteer, but my build system is
> broken (a mess of Gutsy and Feisty packages will do that to ya).
> El Sáb 06 Oct 2007, Allan Sandfeld Jensen escribió:
> > On Saturday 06 October 2007 20:43, Manuel Amador (Rudd-O) wrote:
> > > No, it won't slow down file play, because the DONTNEED hint only
> > > applies to the file descriptor owned by TagLib.  If some other process
> > > holds another file descriptor of the same file open, DONTNEED has no
> > > effect.
> >
> > There is no other thread, the decoder hasn't opened its file descriptor
> > yet.
> >
> > `Allan
> > _______________________________________________
> > taglib-devel mailing list
> > taglib-devel at
> >

More information about the taglib-devel mailing list