Profiling cpu
Plug-and-play skills and prompts for every AI coding agent
npx -y skills add Amey-Thakur/AI-SKILLS --skill profiling-cpuAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Find the code that actually burns CPU time using a sampling profiler and a flame graph instead of guesswork. Use when a program is slower than it should be and you need to locate the hot path before touching any code.
SKILL.md
3.0 KB, as published. Nobody here has run it
Profiling CPU
Intuition about what is slow is wrong often enough that acting on it wastes days. The bottleneck is rarely the clever algorithm you remember writing; it is a string format in a loop or a lock nobody noticed. A profiler replaces the guess with a measurement of where cycles go.
Method
- Reach for a sampling profiler, not an instrumenting one. Sampling
interrupts the program hundreds of times a second and records the stack:
perf record -F 999 -g -- ./appon Linux,py-spy record -o out.svg -- python app.pyfor Python,async-profilerfor the JVM. Instrumenting every call (likecProfile) distorts the very timings you are measuring. - Profile a release build under a real workload. Debug builds and toy inputs move the hot spot somewhere it will never be in production. Compile with optimizations on, feed the profiler the traffic or dataset that actually hurts, and run long enough to collect tens of thousands of samples so the numbers are stable.
- Read the flame graph by width, not by height. Width is time: the widest frame at any level spent the most CPU. Height is only call depth and means nothing on its own. Scan the top edge of the graph, the leaf frames doing the actual work, and find the widest plateau.
- Separate self time from total time. A function wide because its
children are wide is not the culprit; drill into the child. A leaf that is
wide with no children below it is burning cycles itself: that is where an
optimization pays off.
perf reportshows this split as self vs children. - Follow surprise frames into system and runtime code. A fat
malloc,memcpy, garbage-collection, or futex plateau names the real problem: allocation churn, copying, or lock contention rather than your arithmetic. The named syscall or runtime function tells you which fix applies before you read a line of your own source. - Fix the widest bar, then reprofile from scratch. Optimizing anything but the top item moves numbers you will not feel. After one change, capture a fresh graph: the hot spot has usually moved, and the old profile no longer describes the program.
Litmus tests
- Can you name the single function with the largest self time, in samples?
- Did the graph come from an optimized build under representative load?
- After your change, did the widest plateau shrink or just shift elsewhere?
Boundaries
A CPU profile explains where compute goes, not where wall-clock time goes. A program blocked on disk, network, or a lock sits idle off-CPU and barely appears; use off-CPU profiling or tracing for that. For allocation pressure specifically, an allocation profiler attributes the churn more directly.