inlining

[Don]

JAnderson wrote:
> 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.
> 
> -Joel

Yup. Code cache can easily become a bottleneck. Similarly, turning on 
'optimise for speed' for a whole program is almost always a bad idea.

More useful than 'inline', would be some way to tell the compiler 'this 
function is speed-critical'. If nothing else, it would have some 
documentation value.