godot-performance-profilinglisted

# Godot Performance Profiling ## Purpose This skill supplies Godot's measurement tooling. The method — baseline, profile, fix the dominant bottleneck, re-measure — lives in `performance-profiling-method` and is not repeated here. Godot's specific contribution is that its profiler is in the editor and measures the editor-hosted run, which means the numbers include editor overhead. Knowing what that overhead is, and confirming conclusions in an exported build, is the difference between useful measurement and a plausible-looking waste of time. ## When to use - A Godot project misses its frame budget, stutters, or hitches. - Before proposing any Godot optimisation. - Load times or scene transitions are too slow. - Memory grows over a session. - Deciding whether an approach is affordable before committing to it. ## When NOT to use - The problem is a visual artifact rather than cost. Use `render-debugging`. - You already know the bottleneck and need the fixing technique. Use `cpu-optimization` or `gpu-optimization`. - Editor slowness that does not reproduce in an exported build. Worth noting, but it is a different investigation. ## Required context | Fact | Why it matters | Where to find it | |---|---|---| | **Godot major version** | 3.x and 4.x differ in renderer and profiling tools | `config_version` in `project.godot` | | Minor version within 4.x | Renderer and physics behaviour changed across 4.x | `config/features` | | Renderer in use | Forward+, Mobile and Compat