Re: When Not to Use virtual Methods for Performance (Was: game development layout question)

  • From: "Will Pearson" <will@xxxxxxxxxxxxx>
  • To: <programmingblind@xxxxxxxxxxxxx>
  • Date: Sat, 13 Oct 2007 14:57:56 +0100


One more thing.

I wouldn't be overly concerned with the performance cost of virtual function calls unless you are making a lot of function calls.

What may be more concerning than virtual functions is whether you intend to use a lot of branch statements, such as if, for, while, etc. Modern CPU's use an instruction pipeline and break up the processing into stages. As the result of a branch statement isn't known until the branch instruction reaches the end of the pipeline the CPU has to predict the outcome of the branch statement in order to keep the other stages of the pipeline busy whilst the branch statement is being executed. If the CPU mispredicts the branch statement then it has to flush the instruction pipeline and repopulate it, which wastes CPU cycles. Most high performance computing applications contain very few branch conditions for this reason.

----- Original Message ----- From: "Will Pearson" <will@xxxxxxxxxxxxxxxxxxxxx>
To: <programmingblind@xxxxxxxxxxxxx>
Sent: Saturday, October 13, 2007 2:43 PM
Subject: Re: When Not to Use virtual Methods for Performance (Was: game development layout question)


Performance can be a critical factor in some applications. I would include modern games in this category because they are usually bound by a particular frame rate, usually 30Hz. This means that all the collision detection, response, sensory output, and other state updating has to be done within this timeframe. This time boundary in which a response has to be made makes modern games realtime applications.

I agree that algorithm design can often provide the biggest performance savings. For example, an algorithm that runs in O(1) is much better than one that runs in O(n)2; however, if you've got the most appropriate algorithms then the only way in which you can improve performance is to optimise the implementation or kill off features. Although examining the implementation takes quite a lot of time you can usually find some good savings. A profiler will help pick out hot spots that may be potential candidates for optimisation. You can then look at the code for the hot spots and evaluate whether you can implement the same functionality in a way that uses less memory or CPU instructions, depending on whether you are memory or CPU bound. It's worth trying to reduce both the memory and CPU footprint as each can affect each other, for example hard page faults that cost around 10000 cycles.

There are some well known optimisations that can be made. Some of these include loop unrolling, loop flipping, and code hoisting. Some of these optimisations do make the code more difficult to read but it's often more important to have something that works and is useful than something that is usable through usability. You can find a pretty comprehensive, although a little incomplete, list of low level optimisations here:
The optimisations are intended for compilers but you can implement many of them in your own code yourself.

Will __________
View the list's information and change your settings at //

View the list's information and change your settings at //

Other related posts: