Mail Archives: djgpp/2004/12/26/17:15:47
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 -