Date: Wed, 10 Mar 2004 02:49:31 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Alexander Kabaev <ak03@gte.com> Cc: John Birrell <jb@cimlogic.com.au> Subject: Re: cvs commit: src/lib/libc/stdio _flock_stub.c local.h Message-ID: <20040310000922.A5035@gamplex.bde.org> In-Reply-To: <20040309043207.GA65153@kanpc.gte.com> References: <200403090245.i292j0a6035728@repoman.freebsd.org> <20040309032248.GA88649@cat.robbins.dropbear.id.au> <20040309035532.GA88825@cat.robbins.dropbear.id.au> <20040309043207.GA65153@kanpc.gte.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 8 Mar 2004, Alexander Kabaev wrote: > On Tue, Mar 09, 2004 at 03:05:36PM +1100, John Birrell wrote: > > > > I'm not sure that I agree that applications are 'broken' when they > > use things that are defined in the header file along with the FILE > > structure itself. It's a historical mistake that FILE is not opaque. > I would like to see FILE to become transparent to applications and its > definition moved to the libc-private header file with the specific > purpose of making the hack you mentioned impossible. This would pessimize even getc_unlocked() and putc_unlocked(). getc() and putc() are now extern functions, but the old macro/inline versions are still available as getc_unlocked() and putc_unlocked(). Simple benchmarks for reading a 100MB file on an Athlon XP1600 overclocked show that the function versions are up to 9 times slower: Time to read the file from a disk cache using read(): 0.17 seconds (sys) getc_unlocked() overhead: 0.41 seconds (user) getc() overhead: 1.64 seconds (user) This is with static linkage. Dynamic linkage increases the getc() pessimization significantly: read() time: no significant change getc_unlocked() overhead: 0.44 seconds (user) getc() overhead: 3.62 seconds (user) Bruce Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040310000922.A5035>