performance-profiling-methodlisted

# Performance Profiling Method ## Purpose Performance work fails in a specific, predictable way: someone reads the code, forms a theory about what is slow, changes that thing, and declares victory without measuring. The change is usually irrelevant and sometimes harmful, and because nothing was measured, nobody finds out. This skill defines the loop that prevents that: ``` BASELINE -> PROFILE -> IDENTIFY THE DOMINANT BOTTLENECK -> FIX ONE THING -> RE-PROFILE -> COMPARE ``` Every platform-specific performance skill in this toolkit implements this loop with its own tools. The loop itself does not change. ## When to use - Anything is reported as slow, stuttering, hitching, laggy, or dropping frames. - Load times, build times, or startup times are too long. - Memory or VRAM use is too high, or the process is being killed for it. - Someone proposes an optimisation and you need to decide whether it is worth doing. - Before a performance-related release gate. ## When NOT to use - The code is functionally wrong rather than slow. Use `root-cause-debugging`; a correctness bug that also happens to be slow is still a correctness bug. - You are designing a system that does not exist yet. Use `software-architecture` and choose a shape that admits optimisation later; do not micro-optimise a design. - The "slowness" has not been reproduced or quantified by anyone. Reproduce and quantify first, or you are optimising a rumour. ## Required context Establish all of these before