unity-performance

Review hot paths for repeated Find, GetComponent, and Camera.main calls, excessive Update loops, and per-frame allocations from LINQ or string formatting. This Skill provides a structured checklist separating confirmed red flags from speculative issues.

Avoid LINQ queries, string interpolation, closures, and boxing inside Update loops since each creates garbage every frame. Cache component references and use object pooling instead of repeated Instantiate and Destroy calls.

Yes, Debug.Log is not stripped in Player builds, so string interpolation and helper method calls execute every frame in shipped games. Guard log statements with Debug.isDebugBuild or use Conditional attributes to elide them.

Hidden costs like write-permission serialization can poll components every frame regardless of whether writes occur. Components that can mutate transform.position pay dirty-flag costs even when the write branch never runs.

Use pooling when you frequently Instantiate and Destroy similar objects like bullets, enemies, or particles during gameplay. The Skill flags frequent instantiation patterns as red flags but warns against refactoring without a confirmed hotspot.

Profilers rarely catch possibility-based costs like serialization of writable components or correlated RNG streams from sequential seeds. These require code review against known anti-patterns rather than runtime measurement alone.