Mail Archives: djgpp/1999/01/29/21:10:23
> >I'm troubled too, but I think that the diference in access speed is that the
> >DJGPP have to switch to real mode to call DOS funcs and it makes your
> >program slower. Have you tried make your program disk buffer greater.
> >Remember, DJGPP can access much more than 64KB per selector.
> >
> That's probably right. Because recently ported a program from Boarland and
> it ran much faster. I't does allmost not disk access though.
In addition, the way you access the disk makes a difference. Binary
files are faster than text (both compilers), but DJGPP has special
code to optimize FILE* sequential vs random reads. If you use stdio.h
functions to read from the file, and you do a sufficient amount of I/O
to make the startup time negligible, DJGPP should at least be as good
as Borland.
To further describe how this works:
Most C runtimes use a fixed size buffer for stdio streams. It was
difficult to choose a buffer size that was large enough to optimize
sequential reads while small enough to not waste time on small random
reads. So, what DJGPP does is initially assign a small 512-byte
buffer. Each time it needs to fill the buffer for a sequential read,
it doubles the buffer size, up to the size of the transfer buffer.
This doubling is further modified such that disk reads are always on
cluster boundaries. So, if you continue to read sequentially, you end
up reading whole clusters (or multiples of clusters) at a time.
However, if you call fseek() at all, it resets the buffer size back
down to 512 bytes. So, if you tend to do lots of little reads all
over, you will tend to read only those sectors you actually need, and
no more.
We hoped that this would allow each program to adapt to the optimum
for itself, without us having to guess what would be best.
DJ
- Raw text -