www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: inlining

 JAnderson wrote:
 bobef wrote:
 This has probably been asked many times before. If

 such discussion please paste me a link. Why not an

 We all know that the compiler can be stupid some

 is not people may want to inline something that is

 appropriate for inlining. Auto inlining is fine,

 have control over such kind of things I believe.

 Regards, bobef

May C++ compilers ignore the inline attribute because

 handle on when to inline.  There have been some

 have the links to these) where they've shown that

 compiler can make a more intelligent guess then the

 But that's C++.  D does this automatic

 to say whether the compiler can always make a good


I was working with MSVC++ the other day and found a couple of places where it wasn't inlining the code and was running slow. So I placed a few inlines around and *bam* that code started running faster. Then I profiled the code as a whole to see how much of an improvement I'd gained. However the game was actually running slower. It turned out that inlining had simply shifted the bottneck into memory and the program file size had got bigger, so the program cache was stalling all the time. I'm not against inlining, I just think that you have to be really careful when using it and understand its implications (ie use a profiler), otherwise you could be making things worse.

A good point. Recently i've stepped away from C and trying to get away from ultra-optimizing code (which has made my best project look sloppy and i notice is ridden with extra code, in order to get gains that i am not sure i'm actually getting) Could we, for instance use a profiler to comment and pull information from a running program, and than use that to get optimizations that it might otherwise have not noted? I recall something like this, but i don't want to look it up. bare with me.
(not exactly as before, but close)
 if (b)
   a = something;
   a = somethingElse;

Then say b had a 90% chance of being positive or negative, the running profiler seeing that would then take the needed steps on a re-compiling stage using that profiling in order to optimize, without worrying about portability and readability problems? We see the above code, the compiler does... (if b is greater for being positive) a=something; if (!b) a=somethingElse; Course, unless there's something big or slow in the calls, or SomethingElse takes longer than something (besides a simple type), i don't think there's much of a speed gain. If for example the opposite was true.. (if b is greater for being positive) char []buffer; //what for i'm not sure. buffer=something; if (!someflag) buffer=new char[xxx]; Then the speed gains from not having to initialize the memory for some flag is still true, although it wouldn't be much speed gains honestly. hmm.. (Assembly would say, 1 compare, 1 jump, 1 assignment/call, regardless) Oh well. Thoughts on an external profiler to assist with the compiler with optimization? Era
Jul 19 2008