inlining

[Lutger Blijdestijn]

Lutger Blijdestijn wrote:

> spir wrote:
> 
>> On Tue, 07 Dec 2010 13:44:18 +0100
>> Lutger Blijdestijn <lutger.blijdestijn at gmail.com> wrote:
>> 
>>> There are some other conditions that prevent inlining, it's best to
>>> check for it. iirc also functions with loops, delegate and ref
>>> parameters cannot be inlined for example. I'm not so sure about ref,
>>> that may have been improved since the last time I checked. Perhaps also
>>> for some class of delegates, at least ldc supposedly can inline some
>>> functions with delegate parameters.
>> 
>> What do you mean with ref, ref parameters? If yes, why ar they
>> problematic?
>> 
>> Denis
>> -- -- -- -- -- -- --
>> vit esse estrany ☣
>> 
>> spir.wikidot.com
> 
> this:
> 
> void foo(ref int a) { a++; }
> 
> At the time I checked, this function could not be inlined by dmd, which
> can cost performance in some cases.

ok I checked it, it seems the dmd has improved in the meantime and is able 
to inline this case now. 

For reference:

void foo(ref int a ) { a++; }
void bar(int* a ) { a++; }

void main()
{
    int a;
    foo(a);
    bar(&a);
}

compile with -profile -inline -O and run it, it will produce a trace.log and 
trace.def file. The trace.def contain the optimal order in which to link the  
functions, the trace.log file contains a call graph and a table of timings.
(you won't see anything interesting here, because everything is inlined). 
It's a great way to check for performance bottlenecks.