Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > >Non-inline functions have their place in reducing code size
> > > >and easing debugging. I just want an i_foo for every foo that callers
> > > >will have the option of using.
> > >
> > > Before we make any promises to do all that extra work can we
> > > measure (for various architectures) the cost of a real call vs inline.
> > >
> > > I want proof that inline makes X% difference.
> >
> >I'm not going to prove that. A normal C function call involves
> >several instructions and a jump most likely across page boundaries.
>
> But if that function is already in cache from another use, you win.
>
> Assume, for a minute, you've got a 700MHz system with a 100MHz 128-bit data
> bus. If your code is inlined and works out to 256 bytes, that's 16 fetches
> on the main bus. That costs 112 cycles. On the other hand, if your
Dan, you are completely missing my point. Okay, fine, non-inline may
be a performance win in some cases. Inline may be a win in others. I
am not proposing we mandate inlining in any case, I am proposing the
exact opposite: that we let the caller decide in every case.
--
John Tobey, late nite hacker <[EMAIL PROTECTED]>
\\\ ///
]]] With enough bugs, all eyes are shallow. [[[
/// \\\
