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: <8edus09uvkr9or13giuvdflk4ogin5q2l1@4ax.com> References: <6a7us0he1s9ml2djpp5tlm48lod92eei5c 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: 75 Date: Sun, 26 Dec 2004 22:13:39 GMT NNTP-Posting-Host: 24.71.223.147 X-Complaints-To: abuse AT shaw DOT ca X-Trace: pd7tw3no 1104099219 24.71.223.147 (Sun, 26 Dec 2004 15:13:39 MST) NNTP-Posting-Date: Sun, 26 Dec 2004 15:13:39 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 15:34:07 -0500 in comp.os.msdos.djgpp, Radical NetSurfer wrote: >Here we go again! > >I have this program I am helping a friend with.... >He is using DJGPP 2.8.0, and I have 2.953, and >this problem exists in both versions... > >Longest running time to accomplish a single task >was 1 min 40 secs, >after some experimentation, we managed to get that >down to 53 seconds.... > >This still seemed to us to somehow be much longer than it should of >been taking, so we continued substituting different things throughout >the program until we finally stumbled into this: > >'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! > >SECOND ISSUE: >Apparently, from careful study, using multi-dimentional arrays also >takes much more time, then say, directly calucating values on the >fly... so much for thinking embedded tables are always faster! >This was 4-dimentional array of type short. > >'off_t' is defined as a mere 'int' by the way, which in djgpp is >32-bit. > >We discovered that using only _dos_* functions, our program also >consumed much more time than it should; using fread, etc., streaming >file i/o is faster under DJGPP. 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. -- 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