NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/arch/11987

Internet Message Format | 1992-12-29 | 1.7 KB

Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!agate!dog.ee.lbl.gov!horse.ee.lbl.gov!torek
From: [e-mail] (Chris Torek)
Newsgroups: comp.arch
Subject: Re: UNIX fseek time (was Re: Comparison of Alpha, MIPS and PA-RISC-II wanted)
Date: 29 Dec 1992 22:33:15 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
Lines: 24
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: 128.3.112.15

In article <[e-mail]> [e-mail] (David Wright) writes:
>In addition, fseek() is generally moronic about checking whether the
>new file pointer is within the current buffer.  That is to say, it
>doesn't check.  So if you, say, try to read a file backwards, one byte
>at a time, you'll do as many reads as there are bytes in the file.

Speak for yourself. :-)

I wrote most of the 4.4BSD stdio (bugs and all---so far we have found
and fixed three or four).  My fseek() can read a file backwards fairly
quickly.  You will do better if you read() directly---no general
subroutine can be perfectly optimal for all tasks---but there is no
longer an order of magnitude slowdown for short backwards seeks when
reading.

(Note that, when writing, fseek must perform an fflush(), which translates
into a write and thus may involve block allocation and other very slow
tasks.  The code for reading is largely separate.)

None of this has anything to do with UNIX: fseek()'s operation is
defined by ANSI standard X3.159-1989 and its various equivalents.
--
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE ([phone])
Berkeley, CA        Domain:    [e-mail]