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

[Manuel Amador (Rudd-O)]

You're welcome, Jeff! :-)  Let's hope this patch provides the performance 
enhancement we've all been waiting for.  And indeed, the Strigi usecase seems 
extremely interesting!

El Jue 11 Oct 2007, Jeff Mitchell escribió:
> 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
> connection...
>
> 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
> assistance!
>
> --Jeff
>
> 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 kde.org
> > > https://mail.kde.org/mailman/listinfo/taglib-devel
>
> _______________________________________________
> taglib-devel mailing list
> taglib-devel at kde.org
> https://mail.kde.org/mailman/listinfo/taglib-devel



-- 

	Manuel Amador (Rudd-O) <rudd-o at rudd-o.com>
	Rudd-O.com - http://rudd-o.com/
	GPG key ID 0xC8D28B92 at http://wwwkeys.pgp.net/

Now playing, courtesy of Amarok: Dr. Alban - Papaya coconut
If you learn one useless thing every day, in a single year you'll learn
365 useless things.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/taglib-devel/attachments/20071011/8915e96d/attachment.pgp