Does C++ compiler optimize virtual member calls? - c++

Question

I'm thinking of creating a big new C++ project. The start is easy - just a simple window, maybe SDL2, maybe SFML, maybe even WIN32. Well, what should I take? Wouldn't it be much nicer to use any window I want to? Without changing much code so that other classes are independent of this window?
Said, done! Using a simple window interface, every class knows of something like a window and I'm able to choose between different types. The only requirement is having IWindow as a base class.
class IWindow {
public:
IWindow(std::string title, int posX, int posY, int width, int height);
IWindow getHandle();
void loop();
bool toggleFullscreen();
bool toggleFullscreen(bool fullscreen);
int getWidth();
int getHeight();
int getPosX();
int getPosY();
//And so on ...
};
But now, since I have to use virtual methods, every time my virtual function loop will be called by the game loop. And virtual functions are slower. About 10%, I've read.
Isn't the compiler able to see what my window will be? Of which type it'll be from? Couldn't it see "Jeah, this programmer guy creates an SDL window in this application, so just use it's methods everywhere."? I mean, I'm defining my window during the main loop and it'll never change. It's nothing dynamical. It's predictable.
So is the compiler able to optimize my predictable virtual function calls? These which will be evaluated every game loop cycle? Like in the following passage?
int main(int argc, char* argv[]) {
//Creates a window derived from IWindow
SDL::Window myWindow("Title", 0, 0, 300, 100);
//Storing it as IWindow in a wrapper class
Game myGame(&myWindow);
//Game loop
//myGame.run() calls the window's loop
while (myGame.run()) {
//... doing game stuff
}
}
With a Game class like this:
class Game {
protected:
IWindow* window;
public:
bool run() {
//Calls the window's virtual loop method.
//Will it be optimized? Any way to do so?
this->window->loop();
}
};
It would be nice to hear of your ideas and experiences.
Darth Moon

Answer 1

Does C++ compiler optimize virtual member calls?
Yes, a compiler might be able to de-virtualize virtual function calls if it can determine the concrete type at compile time.
No, a C++ compiler will not be able to de-virtualize all virtual function calls.
And virtual functions are slower. About 10%
Assuming the 10% difference is correct, consider that function call overhead is probably somewhere in magnitude of a few nano seconds. 10% of a few nano seconds is not a lot. You can fit many, many nano seconds in a single iteration of a soft real time simulation like a game.
Isn't the compiler able to see what my window will be?
So is the compiler able to optimize my predictable virtual function calls?
Maybe.
Firstly, call to run must be expanded inline in the context where the pointer is assigned. Otherwise it cannot make any assumptions about the pointed object. In order to be expanded inline, it must be defined in the same translation unit as where the function is called from (except, LTO may be able to lift this requirement).
Furthermore, the compiler must be able to prove that window is not modified at any point during the execution to point another object. This proof may be impossible depending on what your loop looks like, but there is a simple way to make it easy: declare the pointer const.
As for whether your compiler does optimize it... I don't know. But your compiler does, so I suggest directing your question to your compiler (i.e. ask it to compile your program and see what it does).

Answer 2

Let's sum up our comments.
Virtual calls are costly, but if the processor can detect a pattern, their calling cost gets decreased thanks to the predictors inside modern processors.
Now, let's check your code:
int main(int argc, char* argv[]) {
//Creates a window derived from IWindow
SDL::Window myWindow("Title", 0, 0, 300, 100);
//Storing it as IWindow in a wrapper class
Game myGame(&myWindow);
//Game loop
//myGame.run() calls the window's loop
while (myGame.run()) {
//... doing game stuff
}
}
Let's assume Game has a virtual run. In this instance, the compiler knows that myGame is of type Game and can directly put the call to your run function instead of going through the virtual table.
Now you have this in another file:
class Game {
protected:
IWindow* window;
public:
bool run() {
//Calls the window's virtual loop method.
//Will it be optimized? Any way to do so?
this->window->loop();
}
};
Unfortunately, in this case, there is nothing that the compiler can know by just looking at this file, and as such the call to SDL::Window will go through the virtual run coming from IWindow.
Now with lto (link time optimization), the compiler might be able to figure it out and de-virtualize the code, but it will probably not as the number of optimization options will grow with the number of files as well as the number of combinations.