Lutger Blijdestijn wrote:
> spir wrote:
>
>> On Tue, 07 Dec 2010 13:44:18 +0100
>> Lutger Blijdestijn <lutger.blijdest...@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.
