Does Claude need a profiler to fix SGDK slowdown?

Does Claude need a profiler to fix slowdown in an SGDK game? Not to get there, but it gets there faster with one. I gave Claude Code a Mega Drive scene that runs at 36 game loops per second instead of 60, and a check.sh that builds it and prints either the frame rate only, my old profiler report, or a new profile of each game loop by function. It reached 60 in 12 of 12 runs. With only the frame rate, it found the slow code by switching it off, and took 6 to 27 checks and USD 0.32 to 1.30. With the per-loop profile it took 7 to 14 checks and USD 0.33 to 0.62.

Handing Claude the same profile without a loop, as a single prompt, did nothing: 0 of 5 fixes reached 60. Everything ran headless in the Genesis Plus GX emulator, and nothing was checked on a real console.

Why build a per-loop profile?

This follows the last SGDK test, where Claude fixed this same scene in 0 of 15 one-shot tries, whatever report it got, and in 3 of 3 runs with a build-and-profile script in the loop. The scene is Claude’s own code from the DMA post: two 96x112 fighters drawn in software into RAM and streamed to VRAM.

The trap was in my profiler. mdprof reports per video frame, and a frame cannot be busier than 100%. A game loop that takes two frames shows up as two slices of about 110k cycles, and every reply took one slice for the whole render. The real render costs about 195,000 cycles, one and a half NTSC frames.

So mdprof got one new option, --fncsv, which writes the cycles of every function in every video frame. mdperf then adds them up over each game loop: from the frame where the CPU leaves SGDK’s wait-for-VBlank function to the frame before it leaves it again.

def loop_functions(fn_rows, loops):
    """Each loop's cycles per function, added up over the frames from its start to the frame before the next start."""
    per_frame = {}
    for r in fn_rows:
        per_frame.setdefault(int(r["frame"]), {})[r["function"]] = int(r["cycles"])
    for l in loops:
        fns = {}
        for f in range(l["frame"], l["frame"] + l["frames"]):
            for name, c in per_frame.get(f, {}).items():
                fns[name] = fns.get(name, 0) + c
        l["fns"] = sorted(fns.items(), key=lambda kv: -kv[1])
    return loops

The functions of each loop add up to its busy cycles exactly (0 cycles off in all 43 measured builds). On the original scene, the new section reads:

== Game loops by function (mdperf) ==
budget: 128,005 cycles per video frame (NTSC); a game loop that needs more misses the next VBlank and the frame is shown twice
game loops measured: 479; cycles below are added up over every video frame a loop spans
  160 loops took 1 video frame: busy cycles 20,329 to 20,515 (mean 20,440)
  319 loops took 2 video frames: busy cycles 211,305 to 226,410 (mean 215,375)
most expensive loop #1: loop starting in frame 1321, 226,410 busy cycles over 2 video frames (177% of one frame)
      142,127  fillRect
       44,984  renderFighter
       18,336  memset_
        9,409  flushQueue
        2,380  DMA_queueDmaFast
        1,776  updateFighterSprites.constprop.1

That is the number the old report hid: fillRect alone takes 142k cycles in one loop, more than a whole frame.

Does a per-loop profile help Claude fix slowdown in one shot?

No. Each one-shot fix was a single claude -p call with no tools: the unchanged main.c, one kind of report, and “fix the slowdown without changing what the scene shows”. I built each reply with SGDK 2.11 and measured frames 700 to 1,499 of a 1,500-frame run with a scripted pad. Round two sent each result back with the same kind of report about its own new numbers. Five runs per row, game loops per second:

Report	Round 1	Round 2
none, just the loop rate	36.0, 44.3, 30.0, 36.0, 45.3	59.1, 60.0, 58.6, 60.0, 45.0
DMA + CPU per frame + loop totals (the old report)	29.9, 30.0, 25.9, 30.0, 36.0	58.6, 44.6, 38.4, 36.0, 38.4
DMA + CPU per frame + loops by function (new)	36.0, 25.9, 36.0, 25.7, 30.1	45.3, 36.0, 30.1, 36.0, 44.3

Round one went 0 for 15 again. The only two fixes that reached 60 came in round two with no report at all. Five runs per cell cannot tell “no report is better” from luck, but they rule out the idea that the profile was the missing piece.

The replies show why. With the new profile, one reply out of five put the render at “about 200k cycles”. The others said about 100k, 112k, 100k, and “about 128k, a full frame”. The 142k fillRect line was right there. And the reply that got 200k right still chose the same fix as the rest: render one 32-pixel column per frame, plus a faster fillRect. In four of five replies that column split was the plan, and it cannot fit: a third of 195k for each fighter, with both fighters rendering every frame, is over budget before the game does anything else.

Can Claude fix SGDK slowdown with only the frame rate?

Yes. This is the part I did not expect. I put the scene in a folder with a check.sh that builds src/main.c and prints one kind of report: the frame rate only, the old report (DMA, CPU per frame, loop totals), or the new one (DMA, CPU per frame, loops by function). Claude Code (2.1.322, Sonnet 5.5) got Read, Edit, Write and Bash(./check.sh), a USD 4 cap, and the same instruction: fix it without changing what the scene shows, and stop at 60 or when stuck. Four runs per kind:

check.sh prints	Reached 60	Checks	Minutes	USD at API prices
frame rate only	4 of 4	6, 10, 19, 27	2.5 to 10.5	0.32, 0.45, 1.22, 1.30
old report	4 of 4	10, 12, 15, 20	4.7 to 7.8	0.58, 0.68, 0.68, 0.96
per-loop report	4 of 4	7, 7, 8, 14	2.5 to 4.9	0.33, 0.38, 0.42, 0.62

Added up, the frame-rate-only runs used 62 checks and USD 3.29, the old report 57 and USD 2.90, and the per-loop profile 36 and USD 1.74. The best frame-rate-only run (6 checks, USD 0.32) beat the slowest per-loop run, so with four runs each this is a direction, not a ranking.

What the frame-rate-only runs did instead of profiling is the interesting part. All four switched code off to see what it cost. Run 3 replaced the render call with a comment and ran the check:

-        renderFighter(f->buf, f->nextAnim, f->nextFrame, f->chunk);
+        //EXPERIMENT

That build ran at 60, so it put the call back and cached the idle poses, the fix that worked in the last test too. Its final reply: “With the fighters’ render call disabled, the rate was already 60. I could only see check.sh’s rate output, so I found this by experiment rather than by profiling.” Run 4 stubbed out the rectangle fill (“stubbing it gives 60”) and rewrote it tile by tile. Run 2 disabled rendering first, then checked whether memset or the rectangle fills cost more.

That is a profiler built out of the frame rate, one function at a time. It works on a scene where one thing is clearly the problem. It costs checks, and the logs show it: in three of the four frame-rate-only runs, check.sh printed 60 and then lower numbers again (as low as 25.6), because those 60s were builds with code switched off, not fixes. Only the final main.c of each run counts here, and I measured it myself.

Did the fixes change what the scene shows?

No. A fix that draws less is not a fix, and several runs said they had not compared pixels. So same_scene.py ran the original and all 12 final versions with both fighters standing still and only punch presses, and compared every frame from frame 400 on, half the screen per fighter. All 12 showed exactly the original’s 7 distinct images for the first fighter and 3 for the second, none missing and none new.

The fixes differ in how much headroom they leave. The slowest game loop at the end ranged from 21,726 cycles (17% of a frame, a run that cached all 7 distinct poses at startup) to 121,507 (95%, still rendering punch frames live). Every one of them fits in a frame, but the ones near 90% would not survive much more game.

What did the runs read outside their folder?

Claude Code let the runs read files outside the work folder, and they did. Most opened the harness source to find the compiler flags. Two cases touched the measurement itself, and they are in the audit notes:

• One frame-rate-only run read my log of its own check.sh calls after its 23rd of 27 checks, a build that did not boot. That log also holds the CPU load and the slowest loop, so its last four checks were not frame-rate-only. It had already found the render by switching it off.
• Another read loop_check.py, saw that it can print the full per-loop report, and tried to run it with loopfn. Claude Code refused the command, since only ./check.sh was allowed. Asked to work blind, it went looking for the profiler.

What I would do differently

• Hide the harness. A clean “no profiler” condition needs the check script to be a black box, with the logs out of reach. Next time check.sh will call a small binary in another folder that the agent cannot read.
• A scene with two problems. Switching code off works when one thing dominates. A scene that is both CPU-bound and over the DMA budget would test whether the frame rate alone still points the right way.
• More runs per cell. Four per kind separates “always gets there” from “sometimes”, not 36 checks from 57.

If you use an AI agent on SGDK code, the takeaway from both tests is the same: the report matters less than the loop. Give the agent a way to build and measure its own change, and if you have a profile by game loop, put that in the loop too. It used about 40% fewer checks than either alternative here.

Code, every prompt, reply and report, and the audit notes are in the project folder. The per-loop profile is now part of mdperf, so it works on any SGDK ROM with a symbol.txt.