X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: Radical NetSurfer Newsgroups: comp.os.msdos.djgpp Subject: Re: DREADED fseek Date: Sun, 26 Dec 2004 22:06:28 -0500 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 Organization: Velocity.Net Cache-Post-Path: web.velocity.net!unknown AT 66-211-207-83 DOT velocity DOT net X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/) Lines: 66 X-Complaints-To: abuse AT newshosting DOT com To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com 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 wrote: <--SNIP--> >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! --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.