> JAnderson wrote:
> > bobef wrote:
> >> This has probably been asked many times before. If
> someone knows of
> >> such discussion please paste me a link. Why not an
> 'inline' attribute?
> >> We all know that the compiler can be stupid some
> times, and even if it
> >> is not people may want to inline something that is
> normally not
> >> appropriate for inlining. Auto inlining is fine,
> but people should
> >> have control over such kind of things I believe.
> >>
> >> Regards, bobef
> > 
> > May C++ compilers ignore the inline attribute because
> it has a better
> > handle on when to inline.  There have been some
> studies (does anyone
> > have the links to these) where they've shown that
> most of the time the
> > compiler can make a more intelligent guess then the
> average engineer.
> > 
> > But that's C++.  D does this automatic
> virtual's thing so its difficult
> > to say whether the compiler can always make a good
> choice.
> > 
> > -Joel
> 
> 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;
> else
>   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