Generally, gamers and game devs love to think in terms of FPS or Frames Per Second but it’s better to think of profiling in terms of hertz i.e. cycles or changes per second. So with respect to profiling, 60 FPS should really be considered as 60Hz or 60 updates per second. Then one can start thinking about how long a single update takes and thereby have a goal to shoot for.

In the case of achieving 60Hz, you’re looking at 1/60 or 16.66 milliseconds. Milliseconds are often used since it’s less “fractional” than seconds. It’s easier to speak of shaving off 1 millisecond than 0.001 seconds.

When it comes to reduction of time, it’s important to think of it in absolute terms and not relative. Shaving off 1 millisecond is not the same for a goal of 30Hz (~33 ms) versus 60Hz (~16 ms).

Another thing to consider is that timing is skewed depending on your environment. When building a game, you have various configurations for various purposes such as debugging, testing, submission and so on. Some configurations may have more code running in them than others. Also the machines used for development may not match the machines used by the customer. In other words, bear in the mind the differences between production and live environments and how they can affect the frame rate and your profiling goals.

There are two ways to profile:

• Sampling: Time per function is recorded at regular intervals and relatively analysed
• Instrumented: Chosen function durations are stored absolutely with start and end “probes”

With both methods, the core idea is to determine where abnormal “spikes” in update durations occur. This is profiling in a nutshell. Once problem areas are detected, strategies can be devised based on the situation. Generally, these involve optimizations by removing unneeded calculations or using more “performant” algorithms. Performant is not a real word but it’s a type of jargon used to indicate techniques that perform faster than others.