I'm programming a game in the C# XNA framework and something has been bugging me for quite some time. I'm never certain whether it's to the advantage of a program to save data (that is to say, store it within a local variable) or to calculate it each frame.
While I've decided that it's better to continuously calculate data that changes each frame (such as the position of the player, the positions of automated sprites, et cetera), I'm uncertain whether or not I should save a piece of data like the width of a window or calculate it each frame. My fear is that calculating a piece of data, regardless of how small it may be, sixty times every second will generate quite a bit of overhead, so thus far I've been sticking to saving a lot of material.
Here's an example of what I'm trying to get across:
// Scenario 1: Save the data
// This class represents an entry within a menu.
public class MenuEntry
{
// The constructor takes a SpriteFont variable to calculate the size of
// the given string (which is the text used to represent this entry in a
// menu) and save that data for later access
public MenuEntry(string entryText, SpriteFont font)
{
this.entryText = entryText;
// Initializes a local value of the font to lessen the burden of method calls.
SpriteFont font = menuScreen.GameInstance.MenuFont;
// Initialize the bounding rectangle for this 'MenuEntry' object.
entryRectangle = new Rectangle();
// Based on the text given, adjust the values of the rectangle.
entryRectangle.Height = font.LineSpacing;
entryRectangle.Width = (int)font.MeasureString(entryText).X;
}
// Object methods
// This method simply sets the location of the 'hitbox' of this MenuEntry based
// on the given position.
public void SetLocation(int x, int y)
{
entryRectangle.X = x;
entryRectangle.Y = y;
}
// Object fields
// Rectangle that represents the 'hitbox' for this MenuEntry. In other
// words, the place on the screen over which the mouse can hover to cause
// this MenuEntry to be the selected item on the menu
private Rectangle entryRectangle;
// The 'entryText' is the string representation of this MenuEntry object in
// a menu.
private string entryText;
}
// Scenario 2: Calculate per frame
// This class also represents an entry within a menu.
public class MenuEntry
{
// The constructor simply initializes the value of the text field
public MenuEntry(string entryText)
{
this.entryText = entryText;
}
// Object methods
// Instead of saving the data, these methods allow this MenuEntry
// to calculate its 'hitbox' whenever this method is called,
// returning the width and height variables associated with the
// text representation of this MenuEntry object.
public virtual int GetWidth(SpriteFont font)
{
return (int)font.MeasureString(Text).X;
}
public virtual int GetHeight(SpriteFont font)
{
return font.LineSpacing;
}
// Object fields
// The MenuEntry still must know where it's located, but this component
// is less memory intensive than a 'Rectangle' object (correct me if
// I'm wrong on this one)
private Vector2 position;
// This property allows for the controlling menu to place and replace the
// MenuEntry, though this value must be calculated each frame even though
// the position may be the same for each frame.
public Vector2 Position
{
get { return position; }
set { position = value; }
}
// The 'entryText' is the string representation of this MenuEntry object in
// a menu.
private string entryText;
}
// Example in menu:
public class Menu
{
// For the sake of simplicity, the constructor simply receives a list of entries
// and initializes them to a local variable. If we're using Scenario 1, the
// positions for each rectangle must be set.
public class Menu(SpriteFont menuFont, List<MenuEntry> menuEntries)
{
this.menuFont = menuFont;
this.menuEntries = menuEntries;
#if Scenario 1
Vector2 position = new Vector2(0f, 175f);
for(int i = 0; i < menuEntries.Count; i++)
{
// Initialize a local reference to the current MenuEntry.
MenuEntry menuEntry = menuEntries[i];
// Adjust this entry toward the center of the screen. Assume it
// has access to a static viewport variable.
position.X = Game.Viewport.Width / 2 - menuEntry.GetWidth(this) / 2;
// Set the entry's position to the calculated position. There must be
// casts as these are floating-point values.
menuEntry.SetLocation((int)position.X, (int)position.Y);
// Move down for the next entry the size of this entry
position.Y += menuEntry.GetHeight(this);
}
#endif
}
// This method is called by the main update method once per frame.
public void Update(GameTime gameTime)
{
#if Scenario 1
// Nothing, as the MenuEntry items don't need to move and their positions
// have already been set.
#elif Scenario 2
Vector2 position = new Vector2(0f, 175f);
for(int i = 0; i < menuEntries.Count; i++)
{
// Initialize a local reference to the current MenuEntry.
MenuEntry menuEntry = menuEntries[i];
// Adjust this entry toward the center of the screen. Assume it
// has access to a static viewport variable.
position.X = Game.Viewport.Width / 2 - menuEntry.GetWidth(this) / 2;
// Set the entry's position
menuEntry.Position = position;
// Move down for the next entry the size of this entry
position.Y += menuEntry.GetHeight(this);
}
#endif
}
// Object fields
// The list of MenuEntry items associated with this Menu.
private List<MenuEntry> menuEntries;
// The font used for this Menu.
private SpriteFont menuFont;
}
Though the example is a bit long, I feel as though it adequately encapsulates my question. So, is it better to save more data to an object (in the case of the example, save a rectangle structure) or is it better to calculate this data each frame? Note that the data I'm speaking of doesn't change between frames.
60 times per second in nothing for simple calculations. Your computer can do several million simple calculations per second.
Chose the one that produces the easier to maintain code. And since windows can be resized I strongly recommend recalculating window based stuff like aspect ratio, projection matrix etc on each frame.
Such performance concerns are only relevant for code that gets executed very often. Say >1 million times a second.
For rare execution only expensive calls such as IO matter.
So I'm with svick on this issue: Profile to find the bottleneck and then optimize it. For all other code use the clearest simplest version.