On 31 December 2011 00:48, so <s...@so.so> wrote: > On Fri, 30 Dec 2011 20:48:54 +0200, Walter Bright > <newshou...@digitalmars.com> wrote: > >> On 12/30/2011 7:06 AM, so wrote: >>> >>> I agree @inline (which will probably be an extension) in D should mean >>> force-inline. >>> Ignoring the impossible-to-inline cases (which in time should get >>> better), >>> adding @inline is a few minutes of editing. >>> It will just bypass the cost function and if it is not possible to >>> inline, pop >>> error. >> >> >> >> Sure, but I think you'll be very disappointed in that it isn't going to >> deliver the goods. > > > dmd_inl -O -inline test.d > dmd_inl -O -inline test_inl.d > time ./test > > real 0m4.686s > user 0m3.516s > sys 0m0.007s > time ./test_inl > > real 0m1.900s > user 0m1.503s > sys 0m0.007s > time ./test >
*SNIP* > > void main() > { > for(uint i=0; i<1_000_000_000; ++i) > test(); > } A better compiler would see that the function 'test' has no side effects, and it's return value is unused, so elimates the call to it completely as dead code. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';