Article View: comp.arch
Article #11128Re: UNIX fseek time (was Re: Comparison of Alpha, MIPS and PA-RISC-II wanted)
From: Volker Herminghaus-Shirai
Date: Tue, 29 Dec 1992 21:23
Date: Tue, 29 Dec 1992 21:23
20 lines
1426 bytes
1426 bytes
In article <1477@pacsoft.com> mike@pacsoft.com (Mike Stefanik) writes: > In an article, conor@lion.inmos.co.uk (Conor O'Neill) writes: > >But, given that 'fseek' is incredibly slow on most Unix systems, > >one could almost assume that Unix doesn't support random-access files. > > What do you mean by this? My understanding is that nothing is physically > being done by the call -- it simply sets the byte offset in the file table. > Is the copying of sizeof(off_t) bytes from user space to kernel space > what makes it "incredibly slow", in your opinion? Or did he mix it up with M$-DOS fseek on files opened in "text mode". This is indeed incredibly slow because the file is searched for CR/LFs since CR/LFs count as only one byte (a logical linefeed) in that case. Another brilliant Bill Gates idea, ack! -- Volker Herminghaus-Shirai (vhs@qb.rhein-main.de) Looks good on the outside, but - intel inside
Technical Details
Message-ID:
<1992Dec29.212344.20899@qb.rhein-main.de>Path:
arc1-ca.pugleaf.net!sparky!uunet!spool.mu.edu!umn.edu!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!incom!orfeo!qb!vhsReferences:
<1477@pacsoft.com>Show Full Headers
Complete Article Headers
Newsgroups: comp.arch Path: arc1-ca.pugleaf.net!sparky!uunet!spool.mu.edu!umn.edu!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!incom!orfeo!qb!vhs From: vhs@rhein-main.de (Volker Herminghaus-Shirai) Subject: Re: UNIX fseek time (was Re: Comparison of Alpha, MIPS and PA-RISC-II wanted) Message-ID: <1992Dec29.212344.20899@qb.rhein-main.de> Sender: vhs@qb.rhein-main.de (Volker Herminghaus-Shirai) Reply-To: vhs@rhein-main.de References: <1477@pacsoft.com> Date: Tue, 29 Dec 92 21:23:44 GMT Lines: 20