Performance optimization
Performance work is a measurement discipline, not a bag of tricks. The method is always the
same: profile → find the one bottleneck → fix that → measure again. This skill teaches that
loop and the highest-leverage fixes (pooling, batching, allocation control, asset budgets), and
points you at each engine's profiler. It pairs with physics-tuning for simulation cost.
When to use
- Use when the frame rate is low or uneven, the game stutters/hitches, or it must hit a target
(60 FPS desktop, 30/60 mobile) and currently doesn't. - Use to decide what to optimize: profile, read the frame budget, and identify whether the CPU
or GPU is the bottleneck before changing any code. - Use to apply specific fixes: object pooling, draw-call/batch reduction, removing per-frame
allocations and GC spikes, and setting asset budgets.
When not to use: for physics jitter/tunneling/timestep specifically, use physics-tuning.
For the engine's concrete profiler UI and rendering settings, use that
engine skill (godot-export covers some build settings; engine cores cover the rest). This skill
is the cross-engine method and the shared fixes.
The golden rule: measure first, never guess
Most performance "fixes" applied without profiling target the wrong thing and add complexity for
no gain. Do not optimize code you have not measured. Open the profiler, find the single
biggest cost in a representative scene on representative hardware, and fix that. Re-measure to
confirm the fix helped before moving on. Profile a release/optimized build where it matters —
editor and debug builds lie (editor overhead, no compiler optimization).
Core workflow
- Define the target and reproduce. State the goal (e.g. 60 FPS = 16.67 ms/frame) and find a
repeatable worst-case scene. "Sometimes slow" is unfixable; a reproducible spike is fixable. - Profile before touching code. Run the engine profiler and read the frame: total frame
（为兼容发布已截断）
