inlining

[spir]

On Tue, 07 Dec 2010 16:20:45 +0100
Lutger Blijdestijn <lutger.blijdestijn at gmail.com> wrote:

> 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. 

Right. Tried & worked as you say. Thenk for the tip.

denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com