On Tue, Aug 01, 2000 at 08:55:09PM +0000, [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.
>
> If that proof is there and inline is a "significant win" then
> we teach "PI" or whatever ends up being used instead of #define
> to emit the above when "source" defines foo().
Isn't the whole point of PI to defer decisions like "whether to inline"
until after the target architecture is established and can be tested?!
If perl6 is portable to everything then I imagine the question of
"whether to inline" could have different best answers.
Have folks considered something like:
http://www.tuxedo.org/~esr/kbuild/
?
--
May the best description of competition prevail.
(via, but not speaking for Deutsche Bank)
