I’m working on a game in Unity, and I need some advice on optimizing performance regarding camera movement checks.
Here’s the situation: I have a cutscene where I temporarily lock the camera to a fixed position and prevent the player from moving it. After the cutscene ends, the player should regain control of the camera. Currently, I have a script that continuously checks if the player can move the camera during the cutscene, but I only need this check for a short period during the cutscene itself.
I’m programming on a laptop that isn’t very powerful (I’m 17 and don’t have a part-time job yet), so I try to optimize my code as much as possible. This question just came to my mind while thinking about performance.
My question is:
Is it a good idea to use a boolean flag (e.g., canMoveCamera) to enable/disable the camera movement check, or does that still waste performance since the check is still running in the update loop, even when unnecessary?
Should I completely stop running the script that checks for camera movement after the cutscene is over, or is it okay to just disable the checks and leave the script running in the background?
Additionally, I’ve heard that it only really makes sense to optimize for performance when you actually notice performance issues. Do you think it’s worthwhile to focus on performance optimizations early on, or should I be more relaxed about it until I run into real performance problems? I’d love to hear your thoughts on this.
For all performance and optimization issues, ALWAYS start by using the Profiler window:
Window → Analysis → Profiler
Generally optimization is:
avoid doing the thing that is slow (easiest)
do it fewer times and store its result
do the slow thing less frequently over time
do the slow thing when nobody cares much (during level loading or in another thread, etc.)
find a faster way to do the thing (hardest)
DO NOT OPTIMIZE “JUST BECAUSE…” If you don’t have a problem, DO NOT OPTIMIZE!
If you DO have a problem, there is only ONE way to find out: measuring with the profiler.
Failure to use the profiler first means you’re just guessing, making a mess of your code for no good reason.
Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.
Do not blindly reach for multi-threading or async… understand your performance problems first:
Remember that you are gathering information at this stage. You cannot FIX until you FIND.
Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.
Don’t forget about the Frame Debugger window either, available right near the Profiler in the menu system.
Notes on optimizing UnityEngine.UI setups:
When you are investigating a performance concern, you may even need to create custom tooling or scripts to clearly expose the issue and help you reason about possible solutions. This may even involve making special instrumented builds of your game capable of running on the actual problematic target hardware.
At a minimum you want to clearly understand what performance issues you are having:
running too slowly?
loading too slowly?
using too much runtime memory?
final bundle too large?
too much network traffic?
something else?
If you are unable to engage the profiler, then your next solution is gross guessing changes, such as “reimport all textures as 32x32 tiny textures” or “replace some complex 3D objects with cubes/capsules” to try and figure out what is bogging you down.
Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.
This sort of speculative optimization assumes you’re properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.
“Software does not run in a magic fairy aether powered by the fevered dreams of CS PhDs.” - Mike Acton
Thank you so much for your detailed and helpful response! You really helped me organize my thoughts. Especially your advice not to optimize unnecessarily and to use the Profiler first to address specific issues was exactly what I needed. It’s reassuring to know that I don’t have to stress about performance as long as there aren’t any actual problems.
I’m still quite young (17) and working on a weaker laptop, so I sometimes feel unsure if I’m doing things right. I used AI to help me understand your response and to write this message to thank you because my English skills aren’t very good yet, but I’m working hard to improve them.
Thanks again for taking the time to write such a detailed response. It really helped me a lot