speed on windows

[Sebastian Pipping]

Scott Wheeler wrote:
> On Tuesday 25 July 2006 17:53, Sebastian Pipping wrote:
>> i compared the tag scanning speed of taglib
>> with that of foobar and the result is that
>> scanning 1068 files took 20 seconds with
>> taglib and about 5 seconds the first time
>> with foobar and only 1 second when re-reading.
>>
>> i guess foobar is using some caching/file
>> modification tricks but even the very first
>> time foobar was significantly faster.
> 
> No, that's the disk buffers and is an OS feature -- all OS's do that.  TagLib 
> would be much faster the second go around as well.  I suspect the better 
> numbers later have more to do with the buffering than the API used.
> 
> As for comparisons with Foobar, well, it's hard to say if they're doing the 
> same thing.

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



>> i tried to replace the crt function calls
>> with windows own file api and that decreased
>> the time needed to about 8 seconds which
>> is still slower that foobar but less than
>> half the time taglib needed before.
>>
>> i cannot offer a ready-to-apply patch right
>> now but maybe we should think about this
>> again after the windows-port-question is
>> answered in general.
>>
>> btw does anybody know if there is really
>> no native [...]
> 
> Uhm, fopen() and friends aren't UNIX functions, they're standard C.

------------------------------------------------------------
i know. i guess i didn't put it clear enough.
------------------------------------------------------------



> Just to be clear, I really don't intend to let the code base diverge where not 
> we're not facing real compatibility issues.  (Just as I wouldn't add hack 
> arounds for a super-fast BSD API.)

------------------------------------------------------------
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.

even if CreateFile() and is not faster than fopen()
it still offers more options over for example the sharing
mode of that file. i'm not sure if we can use this here
but what i want to say is that using os-specific functions
behind a os-independent layer in my eyes is a very good idea
in general.

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


sebastian


-- 
Sebastian Pipping
http://www.hartwork.org/