On Tue, 07 Dec 2010 16:20:45 +0100
Lutger Blijdestijn <lutger.blijdest...@gmail.com> wrote:
> 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.
Right. Tried & worked as you say. Thenk for the tip.
denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
