X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
Date:	Sun, 26 Dec 2004 22:21:03 -0500
Message-Id:	<200412270321.iBR3L341028034@envy.delorie.com>
From:	DJ Delorie <dj AT delorie DOT com>
To:	djgpp AT delorie DOT com
In-reply-to:	<fnuus0h720adssrtntlmmv7jku45vlvsqt@4ax.com> (message from
	Radical NetSurfer on Sun, 26 Dec 2004 22:06:28 -0500)
Subject:	Re: DREADED fseek
References:	<6a7us0he1s9ml2djpp5tlm48lod92eei5c AT 4ax DOT com> <8edus09uvkr9or13giuvdflk4ogin5q2l1 AT 4ax DOT com> <fnuus0h720adssrtntlmmv7jku45vlvsqt AT 4ax DOT com>
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

> and that "24 seconds"  applies to his scenario.

Disk I/O is rarely CPU bound, aside from some overhead.  I suspect the
disk subsystem is just more efficient when you give it larger blocks
to read (and don't ask for data you won't be using ;).

> When *not* moviing forward, but having an application that might
> actually require us to fseek BACKWARD (or for that matter randomly)
> I suspect there would some compromises in performance then.

DJGPP's fread/fseek is, amusingly enough, optimized for two programs:
gcc and binutils.  GCC tends to read the whole file at once, and
binutils tends to do lots of seeks and tiny read/writes.

- Raw text -