Mail Archives: djgpp/2004/12/27/10:17:05
On Sun, 26 Dec 2004 22:06:28 -0500 in comp.os.msdos.djgpp, Radical
NetSurfer <RadSurfer AT yahoo DOT com> wrote:
>On Sun, 26 Dec 2004 22:13:39 GMT, Brian Inglis
><Brian DOT Inglis AT SystematicSW DOT Invalid> wrote:
>>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!
>>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.
>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.
How big is that file and how fast are the disk drives?
>setvbuf _also_ took considerably LONGER than we expected,
>when using values other than 128 bytes...
128 bytes was okay for CP/M and 8" SSSD floppies.
512 is a minimum for I/O buffers on just about any drive since then.
I don't bother using setvbuf unless using the 8-32KB range.
Make sure the size is n*1024 otherwise you may get worse performance.
>I have used setvbuf before, and it only improves throughput in certain
>cases; which appear to be rare for me.
I've used it to improve performance dramatically for sequential reads.
>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.
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian DOT Inglis AT CSi DOT com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
- Raw text -