This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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