This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: expected_retval attribute proposal


"Martin v. Loewis" wrote:
> 
> > I4ve had basically malloc (with inexpected value of NULL),
> In any case, I'd expect the overhead of the malloc implementation to
> be magnitudes larger than the performance difference obtained from
> better branch prediction; the same goes for getc, fputc and other
> common memory management/stdio functions.

I agree. In fact, as the putc/getc[1] macros are basically
	need_more_buffer_p ? fill_buffer () : *buffer[pos++]
it's the expected value of need_more_buffer_p which is important --
which we've now covered.

Jan:
>Perhaps most interesting cases would be in stuff like WWW servers etc where
>performance matters and I would expect a lot of such calls there...
In Apache, the bottle neck is the number of system calls. There was some
work done on that a few months back which, IIR, halved the number from
something like 26 to 13 and vastly improved the throughput.

IMO, for {un}expected return value to be useful, it must be determined
automatically (like profiling), and therefore apply to all functions.
How that is achieved is difficult I guess :-)

nathan

[1] IMHO anyone using these macros when needing high-performance IO gets
what they deserve.
-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]