Profiling is like detective work, unraveling the mysteries of why performance in your application is lagging, or why code is allocating excess memory.
Profiling tools ultimately help you understand what’s going on “under the hood” of your Unity project. But don’t wait for significant performance problems to start showing before digging into your detective toolbox.
The best gains from profiling are made when you plan early on in your project’s development lifecycle, rather than just before you are about to ship your game. It’s an ongoing, proactive, and iterative process. By profiling early and often, you and your team can understand and establish a “performance signature” for the project. If performance takes a nosedive, for instance, you’ll be able to easily spot when things go wrong, and quickly remedy the issue.
You can also make before-and-after performance comparisons in smaller chunks by using a simple three-point procedure: First, establish a baseline by profiling before you make major changes. Next, profile during the development to track performance and budgeting, and finally, profile after the changes have been implemented to verify whether they had the desired effect.
You should aim to profile a development build of your game, rather than profiling it from within the Unity Editor. There are two reasons for this:
- The data on performance and memory usage from standalone development builds is much more accurate compared to results from profiling a game in-Editor. This is due to the Profiler window recording data from the Editor itself, which can skew the results.
- Some performance problems will only appear when the game is running on its target hardware or operating systems, which you’ll miss if you profile exclusively in-Editor.
Source: Unity Technologies Blog