From owner-freebsd-hackers Fri Jun 16 05:00:14 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id FAA09112 for hackers-outgoing; Fri, 16 Jun 1995 05:00:14 -0700 Received: from sequent.kiae.su (sequent.kiae.su [144.206.136.6]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id EAA08995 for ; Fri, 16 Jun 1995 04:58:43 -0700 Received: by sequent.kiae.su id AA01660 (5.65.kiae-2 ); Fri, 16 Jun 1995 15:57:32 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Fri, 16 Jun 95 15:57:32 +0400 Received: (from ache@localhost) by astral.msk.su (8.6.8/8.6.6) id PAA00897; Fri, 16 Jun 1995 15:47:42 +0400 To: hackers@FreeBSD.org, Peter Wemm References: In-Reply-To: ; from Peter Wemm at Fri, 16 Jun 1995 15:51:04 +0800 (WST) Message-Id: Organization: Olahm Ha-Yetzirah Date: Fri, 16 Jun 1995 15:47:42 +0400 (MSD) X-Mailer: Mail/@ [v2.38 FreeBSD] From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= aka "Andrey A. Chernov, Black Mage" X-Class: Fast Subject: Re: penalty of using off_t for arithmatic with gcc's long longs? Lines: 49 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 2037 Sender: hackers-owner@FreeBSD.org Precedence: bulk In message Peter Wemm writes: >I was working on my backlog of patches for NN and I just came to ache's >set that he mailed me (via nn-bugs) Quite Some Time Ago(TM). (I'm >currently merging in the Tk X11 code) >One of the things that he did was to substitute many off_t's to longs. >Now that I think about it, I presume there's a performance penalty for using >off_t in general arithmatic.. Is this enough to worry about? >For example, the code that I inherited in nn uses off_t's quite >extensively for all sorts of things, including (for example) offsets of >article body text relative to the beginning of headers, and it's >scattered throughout other data structures. >I guess it's not too important to be able to read > 2GB news articles, >but is it worth trading this for speed? How much is there to gain? What Basic problem isn't performance but several others affected NN: 1) fseek argument: it is "long" per POSIX standard. You can't read > 2GB in POSIX enviroment in any case with 4bytes longs using fseek. NN use fseek(..., (off_t)x, ...), which obviously miss with "long long", really it becomes fseek(..., 0, garbadge) when fseek used without prototype. Really it not hits when prototype exists, but many of my NN off_t->long casts caused by gcc warning about mixing types. 2) printf %ld or %d format can't handle off_t correctly (%qd is correct). NN hits some times with it printing 0 here and breaks followed argumens. It cause converting some structure members from off_t to long in my patch. >about the implicit casts with passing a smaller type to lseek()? If you include , you don't need to cast lseek() argument to off_t. -- Andrey A. Chernov : And I rest so composedly, /Now, in my bed, ache@astral.msk.su : That any beholder /Might fancy me dead - FidoNet: 2:5020/230.3 : Might start at beholding me, /Thinking me dead. RELCOM Team,FreeBSD Team : E.A.Poe From "For Annie" 1849