current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
Stack Overflow is a community of 4.7 million programmers, just like you, helping each other.

Join them; it only takes a minute:

Sign up
Join the Stack Overflow community to:
  1. Ask programming questions
  2. Answer and help your peers
  3. Get recognized for your expertise
up vote 0 down vote favorite

So let's say I have a class here called 'Game'. The other method(s), constructor(s) and destructor(s) are completely neglected in my example and are not important or relevant to my question at hand.

// Game.hpp
#pragma once

class Game { 
public:
    ...
    bool isRunning() { return mRunning; } // See: mRunning
    ...
private:
    bool mRunning; // Holds if the game is running or not
};

Okay, simple enough right? Now here is where my concern is:

// main.cpp

#include "Game.hpp"

int main(int argc, char* argv[]) {
    Game game;

    if (game.isRunning()) {
        ...
    }

    return EXIT_SUCCESS;
}

What is the difference between that and?:

// main.cpp

#include "Game.hpp"

int main(int argc, char* argv[]) {
    Game game;

    bool running = game.isRunning();

    if (running) {
        ...
    }

    return EXIT_SUCCESS;
}

So here is my question: Is there any performance loss/gain at hand? This also applies to bracket scopes I realise. But in terms of performance, does this get optimized? Is it up to the compiler?

share|improve this question
3  
If any compiler produces different assembly for those two examples (with optimizations), throw it away and use a sane compiler. – dyp Jun 11 '13 at 3:35
1  
c2.com/cgi/wiki?PrematureOptimization – jmucchiello Jun 11 '13 at 3:51
up vote 3 down vote accepted

It's up to the compiler to optimize this. The function is probably going to be inlined, and the temporary variable will probably not be stored anywhere other than a register.

What you are actually doing here is "premature optimization", which is an insidious form of procrastination that will stop you from actually writing your game. Write your game first, and then find the bottlenecks. This won't be one of them.

share|improve this answer
up vote 2 down vote

The best way to determine if something will impact performance is to check if it does by using a profiler.

In this case, performance will not be impacted because declaring a single variable in this way uses trivial memory and CPU time, but it is a good practice - especially as a developer of games, where performance is everything - to learn to analyze your own code for performance.

share|improve this answer
up vote 2 down vote

Space efficiency wise there is an obvious (though trivial) disadvantage. Speed efficiency wise, technically the first is more efficient, but again, its so trivial it doesnt matter. The only case where this might possibly matter is if you have - 

bool running = game.isRunning();

loop(...){
    if(running);
}

In this case storing the variable would increase efficiency in a potentially notable way (especially if isRunning becomes a more complicated function).

share|improve this answer
up vote 1 down vote

The function is defined within the declaration of your class, so it's implicitly inline and the definition is visible to anything including your header. Most modern compilers will, with optimisations turned on, do the right thing here.

However, if you were to pull the implementation of Game::isRunning() into a separate translation unit (think "source file"), you would suffer function call overhead on every call it isRunning(). Whether this matters is a different story.

Note also that some configurations of some compilers will not optimise the code with the isRunning() member function too well because not everything happens after inlining. You almost certainly shouldn't worry about this.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.