Mail Archives: djgpp/2004/12/26/22:16:41
By the way, I am using a Gateway 1 gigahertz machine under
winblows 98SE, and my friend is using something like a
266 Mhz sysem, under win95,
and that "24 seconds" applies to his scenario.
setvbuf _also_ took considerably LONGER than we expected,
when using values other than 128 bytes...
I have used setvbuf before, and it only improves throughput in certain
cases; which appear to be rare for me.
Thanks for the great insights though... we were kinda leaning in those
directions, and this verifies some suspicions.
When *not* moviing forward, but having an application that might
actually require us to fseek BACKWARD (or for that matter randomly)
I suspect there would some compromises in performance then.
On Sun, 26 Dec 2004 22:13:39 GMT, Brian Inglis
<Brian DOT Inglis AT SystematicSW DOT Invalid> wrote:
<--SNIP-->
>On Sun, 26 Dec 2004 15:34:07 -0500 in comp.os.msdos.djgpp, Radical
>NetSurfer <RadSurfer AT yahoo DOT com> wrote:
>
>>Here we go again!
>>
>>'Forward_Bytes' is a long defining how much forward into the
>>file we simply wish to set....
>>
>>fseek(File, Forward_Bytes, SEEK_CUR);
>>
>>takes absolutely posititively GREATER time to achieve, then
>>actually reading in bytes to move forward, thus:
>>
>>Dummy is an unsigned char of large enough size...
>>
>>fread(Dummy, 1, Forward_Bytes, File);
>>
>>OK! Sitting down?
>>
>>Using the fread() method the program now achieves its goal
>>in a mere 24 seconds !!!!
>>
>>This is compared to the 53 seconds we could only achieve by making
>>all other practical changes in critical areas of the program...
>>
>>This is quite curious!! WHY SHOULD fseek(), we assumed simply
>>moves forward into a file without having to actually retrieve bytes,
>>TAKE MUCH LONGER than *actually* using fread() to fully
>>retrieve those bytes!
--SNIP--
>If distance to seek forward is less than the I/O buffer size, I can
>see why the read of prebuffered data might be faster than a seek,
>which might involve checking the current file size.
>
>If you use setvbuf() *immediately after fopen()* to increase your
>buffer size to 4/8/16KB, that technique may work even faster.
>
>The fastest way is fstat() to get the file length, malloc() a file
>length buffer (or perhaps some portion for a very large file),
>setvbuf() to the buffer, and do a single fread, then play in memory.
>If the system supported mmap(), you could get the same effect via
>paging, without explicitly tying up all that allocated real memory at
>once.
- Raw text -