X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Trace-PostClient-IP: 68.147.177.20 From: Brian Inglis Newsgroups: comp.os.msdos.djgpp Subject: Re: DREADED fseek Organization: Systematic Software Message-ID: References: <6a7us0he1s9ml2djpp5tlm48lod92eei5c AT 4ax DOT com> <8edus09uvkr9or13giuvdflk4ogin5q2l1 AT 4ax DOT com> X-Newsreader: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 83 Date: Mon, 27 Dec 2004 15:14:24 GMT NNTP-Posting-Host: 24.71.223.147 X-Complaints-To: abuse AT shaw DOT ca X-Trace: pd7tw3no 1104160464 24.71.223.147 (Mon, 27 Dec 2004 08:14:24 MST) NNTP-Posting-Date: Mon, 27 Dec 2004 08:14:24 MST To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On Sun, 26 Dec 2004 22:06:28 -0500 in comp.os.msdos.djgpp, Radical NetSurfer wrote: >On Sun, 26 Dec 2004 22:13:39 GMT, Brian Inglis > wrote: >>On Sun, 26 Dec 2004 15:34:07 -0500 in comp.os.msdos.djgpp, Radical >>NetSurfer 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