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
Precedence: bulk


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