X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: Radical NetSurfer Newsgroups: comp.os.msdos.djgpp Subject: DREADED fseek Date: Sun, 26 Dec 2004 15:34:07 -0500 Message-ID: <6a7us0he1s9ml2djpp5tlm48lod92eei5c@4ax.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-204-236 DOT velocity DOT net X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/) Lines: 57 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 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. THANKS for your valued discussion. email: RadSurfer AT yahoo DOT com