Unity Performance Red Flags

Before calling any skill in this module: if you are about to call a skill with parameters guessed from its name or description, STOP — read this file (or fetch its schema via GET /skills/recommend?includeSchema=true) first. If you already have the parameter definitions from recommend/schema, you may proceed straight to dryRun.

Triggers

• Reviewing performance
• Diagnosing frame drops
• Reducing allocations
• Planning pooling/optimization
• 做性能审查、诊断掉帧或卡顿、减少内存分配、规划对象池/优化

Unity Performance Red Flags

Use this skill for a high-signal review of likely Unity performance issues. Focus on red flags, not speculative micro-optimizations.

Check For

• Too many unrelated Update / LateUpdate / FixedUpdate loops
• Repeated Find, GetComponent, Camera.main, or tag lookups in hot paths
• Frequent Instantiate / Destroy suitable for pooling
• Avoidable per-frame allocations:
  • LINQ
  • string formatting
  • closures
  • boxing
• Reflection in runtime hot paths
• Expensive editor-only helpers leaking into runtime code
• Physics, animation, or UI updates happening at the wrong cadence

Hidden Costs: Possibility ≠ Actuality

Three counter-intuitive traps where what seems "free" is actually expensive. Each cost is paid for possibility of work, not for work actually performed — which is why profilers rarely catch them directly.

Write permission costs, even without writing

A component whose Update can mutate transform.position pays the cost whether the branch runs or not: dirty-flag and serialization systems treat write permission as a reason to poll every frame. Similarly, a [SerializeField] field that is never modified at runtime still sits on the serialization path. The fix is to remove the permission, not tighten the branch — split the rarely-needed writer into its own component and AddComponent only when needed. Source: NetcodeSamples/HelloNetcode/2_Intermediate/07_Optimization/Optimization.md — "a system with the possibility of writing to a component, regardless of whether it writes to it or not, will always have to be serialized".

Sequential seeds produce correlated random streams

Seeding N RNG instances with baseSeed + i gives N similar streams — patrol paths line up, spawn jitter clumps, loot rolls cluster. Hash the index before seeding:

// Wrong — N correlated streams
for (int i = 0; i < N; i++) rngs[i] = new System.Random(baseSeed + i);