Jump to content
  • Advertisement
Sign in to follow this  
Alundra

Inline

This topic is 2141 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

My question is quite simple :

is inline still needed nowadays ?

I show you two cases :

inline IGameState* CGameStateManager::GetCurrentState()
{
    return m_CurrentState;
}
inline void CGameStateManager::Clear()
{
    for( UInt32 i = 0; i < m_GameStateArray.GetSize(); ++i )
        SAFE_DELETE( m_GameStateArray[ i ] );
    m_GameStateArray.Clear();
}

Thanks

Edited by Alundra

Share this post


Link to post
Share on other sites
Advertisement

Sometimes. The first one makes sense (small func, declared outside class def, inline is required to prevent linker error - multiple symbols defined). The second one is a waste of time.

Share this post


Link to post
Share on other sites

The second one is a waste of time.

I don't understand why it's a waste of time. Do you mean the perf will be worst using inline on this case ?

Share this post


Link to post
Share on other sites
The major advantage of the inline keyword is not as a compiler hint to inline, but as a way to put the function in the header, so that the function can be inlined at module compile time, instead of link time. Compilers are more aggressive at modular inlining than link time inlining. So there is an advantage to putting a function body in the header and declaring it inline.

Share this post


Link to post
Share on other sites

 

The second one is a waste of time.

I don't understand why it's a waste of time. Do you mean the perf will be worst using inline on this case ?

 

 

How often are you going to call that function? My guess is, not very often at all. Once per frame? Once per game? What benefit are you *actually* going to see from inlining it? It features a loop which calls delete/free repeatedly, and then calls a function call. It's a big stretch of the imagination to call this a 'small' function. That place, where you're calling it, will it benefit from the additional size required to store those instructions in the instruction cache + additional decoding required? My guess is that no, it won't benefit from being made *slower*.

Inlining is not a toy. It is a tool that *can* help improve performance in *some* cases. Use it sparingly, and only in places that absolutely will be of benefit (e.g. the first example). If you make a habit of inlining functions such as the second example, you will start seeing profiler traces that are 'warm all over' rather than being able to identify any particular hotspots. Remember: CPU's are optimised towards executing 'crap' code efficiently. The CPU like functions. It's designed to execute them quickly. Help your CPU out by splitting your code into nice small functions, rather than huge serial lists of repeating instructions (which is what inline gives you). 

Share this post


Link to post
Share on other sites
As others have said before me, seeing inline as something performance-related is not really valid on modern compilers. They either take it as a vague hint or completely ignore it for optimization purposes.

Being able to write the function body in a header is a completely different beast though. While you can argue for and against doing that, there are some cases where it is required, most specifically once templates are involved. And if you favor compile-time polymorphism over runtime polymorphism, there are quite a few spots where templates can creep in.

Share this post


Link to post
Share on other sites

They either take it as a vague hint or completely ignore it for optimization purposes.

 

Unless you are making heavy use of DLL's, in which case, they will be compiled into multiple binaries (or always exported, depending on how you export the class)

 

While you can argue for and against doing that, there are some cases where it is required, most specifically once templates are involved. 

 

Yes / No / Maybe. If the likely types are known in advance (e.g. Vec3<float>, Vec3<double>), then the code can exist in the cpp, and you simply declare the valid specialisations. If the types are NOT known in advance, then the code may need to exist in the header, but the specialisations can be forced to exist within a single compilation unit. 

Share this post


Link to post
Share on other sites

ok, so, based on all I read, inline is only enough for set/get and all other stuff should be in a .cpp and the compiler will do the job.

Do I understand correctly ?

Share this post


Link to post
Share on other sites

Basically, yes. When you come the end of your project, it is worth running it through vtune/gprof to see if any functions stand out as a big spike. Try inlining those methods, and it may help performance (It might not, since the compiler may already be inlining them). 

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!