Mail Archives: djgpp/2004/12/26/15:46:32
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
- Raw text -