Minimizing ongoing code changes

Making code changes to the application in order to hunt down performance issues is best done carefully, as the changes are easy to forget as time wears on. Adding debug logging statements to our code can be tempting, but remember that it costs us time to introduce these calls, recompile our code, and remove these calls once our analysis is complete. In addition, if we forget to remove them, then they can incur unnecessary runtime overhead in the final build since Unity's debug Console window logging can be prohibitively expensive in terms of both CPU and memory.

A good way to combat this problem is to add a flag or comment anywhere we made a change with our name so that it's easy to find and remove it later. Hopefully, we're also wise enough to use a source control tool for our code base, making it easy to differentiate between the content of any modified files and revert them to their original state. This is an excellent way to ensure that unnecessary changes don't make it into the final version. Of course, this is by no means a guaranteed solution if we also applied a fix at the same time and didn't double-check all of our modified files before committing the change.

Making use of breakpoints during runtime debugging is the preferred approach, as we can trace the full callstack, variable data, and conditional code paths (for example, if-else blocks), without risking any code changes or wasting time on recompilation. Of course, this is not always an option if, for example, we're trying to figure out what causes something strange to happen in one out of a thousand frames. In this case, it's better to determine a threshold value to look for and add an if statement, with a breakpoint inside, which will be triggered when the value has exceeded the threshold.