From: "Rafael García" <rafael AT geninfor DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: performance
Date: Sat, 30 Jan 1999 12:24:37 +0100
Organization: CTV/JET
Lines: 21
Message-ID: <78uquh$bhe$1@lola.ctv.es>
References: <39AE1D927549D111A88F00A0C94B9C7D628ECB AT RJ01MAI01> <J_rs2.41$am3 DOT 436396 AT news DOT bctel DOT net> <199901300209 DOT VAA31138 AT envy DOT delorie DOT com>
NNTP-Posting-Host: infon130.jet.es
X-Trace: lola.ctv.es 917696273 11822 195.55.156.130 (30 Jan 1999 11:37:53 GMT)
X-Complaints-To: usenet AT lola DOT ctv DOT es
NNTP-Posting-Date: 30 Jan 1999 11:37:53 GMT
X-Newsreader: Microsoft Outlook Express 4.72.2106.4
X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com


DJ Delorie escribió en mensaje <199901300209 DOT VAA31138 AT envy DOT delorie DOT com>...

>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.
>


Yes! I can read an 8Mb file in less of middle time with gcc than BC

Thanks