X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
X-Trace-PostClient-IP:	68.147.177.20
From:	Brian Inglis <Brian DOT Inglis AT SystematicSW DOT Invalid>
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
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 <RadSurfer AT yahoo DOT com> 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

- Raw text -