cvs commit: src/lib/libc/stdio _flock_stub.c local.h

[Alfred Perlstein]

* Bruce Evans <bde at zeta.org.au> [040309 07:50] wrote:
> 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)

Hmm, can't we use macros that do this:

#define getc()	(__isthreaded ? old_unlocked_code : getc_unlocked())

Where __isthreaded is a global that's set by threading libraries
to 1 and 0 by non-threaded libc, this should get rid of a lot of
the function call overhead.


-- 
- Alfred Perlstein
- Research Engineering Development Inc.
- email: bright at mu.org cell: 408-480-4684