speed on windows

[Scott Wheeler]

On Wednesday 26 July 2006 2:03, Sebastian Pipping wrote:

> ------------------------------------------------------------
> i scanned with taglib again after a fresh reboot
> and the speedup was gone. probably you are right -
> i apologize.
> ------------------------------------------------------------

Note that for an even semi-valid comparison the same thing would need to be 
done with Foobar.  In practice unless they're reading a lot less of the file, 
which isn't likely, both ID3v2 implementations are going to be more limited 
by disk speed than which APIs they're using to read files.

Also note that reading the files first with TagLib will fill the disk buffers, 
so you can't scan with TagLib and then scan with Foobar and compare those 
numbers.

> you put all the file accessing code in a single class
> which was a good idea. since it is so isolated in my eyes
> it would be a good idea to add as many os-dependent
> speed-hacks to this class as possible.

Nope.  Sorry.  Not going to happen.  Maintainability is more important to me 
than OS-dependant speed hacks.  For example, there are also wide performance 
differences in STL implementations, but I don't intend to add speed hacks 
throughout the toolkit for Sun's STL or MS's...

(Of course the LGPL gives you the right to maintain a fork with such if you so 
desire.)

But again, disk speed is the main bottleneck.

All of that said, there's still no real substance to the current discussion -- 
real profiling often produces useful information, but just guessing which 
functions might be slow probably won't.

> this brings me back to unicode filename support under
> windows which we will have to use different open-functions for
> anyway.

That's what I would call "a real compatibility issue" and is much less 
invasive than rewriting the entire file class.

Cheers,

-Scott

-- 
New Orleans food is as delicious as the less criminal forms of sin.
 --Mark Twain