Date: Fri, 16 Jun 1995 15:51:04 +0800 (WST) From: Peter Wemm <peter@haywire.DIALix.COM> To: hackers@freebsd.org Subject: penalty of using off_t for arithmatic with gcc's long longs? Message-ID: <Pine.SV4.3.91.950616153207.24890B-100000@haywire.DIALix.COM>
next in thread | raw e-mail | index | archive | help
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 about the implicit casts with passing a smaller type to lseek()? Basically, I'm trying to decide is it worth parameterising an "offset" type? Machines like alpha's etc are not going to be too fussed, because off_t == long == 64 bits. BTW: is this appropriate for hackers? I dont know that it's appropriate to "ports" because what I'm asking about is not specifically about software in some /usr/ports area - it's a generic problem that happqens to appear on freebsd and other 32bit 4.4Lite + gcc2 systems (including netbsd). Cheers, -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.91.950616153207.24890B-100000>