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

- Raw text -