Evaluating Performance Problems

 Performance evaluation for most software products is a very scientific process. First, we determine the maximum/minimum supported performance metrics, such as the allowed memory usage, acceptable CPU consumption, and the number of concurrent users. Next, we perform load testing against the application in scenarios with a version of the application built for the target platform, and test it while gathering instrumentation data. Once this data is collected, we analyze and search it for performance bottlenecks. If problems are discovered, we complete a Root Cause Analysis (RCA), and then make changes in the configuration or application code to fix the issue and repeat it.

Although game development is a very artistic process, it is still exceptionally technical. Our game should have a target audience in mind, which can tell us what hardware limitations our game might be operating under and, perhaps, tell us exactly what performance targets we need to meet (particularly in the case of console and mobile games). We can perform runtime testing on our application, gather performance data from multiple subsystems (CPU, GPU memory, the physics engine, the Rendering Pipeline, and so on), and compare them against what we consider to be acceptable. We can then use this data to identify bottlenecks in our application, perform additional instrumentation measurements, and determine the root cause of the issue. Finally, depending on the type of problem, we should be capable of applying a number of solutions to improve our application's performance.

However, before we spend even a single moment making performance fixes, we will first need to prove that a performance problem exists. It is unwise to spend time rewriting and refactoring code until there is a good reason to do so since pre-optimization is rarely worth the hassle. Once we have proof of a performance issue, the next task is figuring out exactly where the bottleneck is located. It is important to ensure that we understand why the performance issue is happening; otherwise, we could waste even more time applying fixes that are little more than educated guesses. Doing so often means that we only fix a symptom of the issue, not its root cause, and so we risk it manifesting itself in other ways in the future, or in ways we haven't yet detected.

In this chapter, we will explore the following:

• How to gather profiling data using the Unity Profiler
• How to analyze Profiler data for performance bottlenecks
• Techniques to isolate a performance problem and determine its root cause

With a thorough understanding of the problems you're likely to face, you will then be ready for the information presented in the remaining chapters, where you will learn what solutions are available for the types of issue we detect.