Enter planning mode. Scan the codebase for MCode optimization opportunities. Use parallelism where possible.
MCode replaces AHK-interpreted tight loops with native C machine code embedded as base64. The project already has an MCode pipeline (tools/native_benchmark/native_src/) and a working example (src/gui/icon_alpha.ahk). Adding a new function to an existing MCode module is low cost — the infrastructure exists.
What Qualifies
All four must be true:
- Hot path — called frequently OR scales with data (per-window, per-pixel, per-byte). Use
query_function_visibility.ps1 to check call frequency — a loop called 1x/session vs 100x/sec changes the MCode ROI. Use query_callchain.ps1 <funcName> -Reverse to trace all invocation contexts. Use query_timers.ps1 to check if the candidate is inside a timer callback (hot path signal).
- Pure buffer computation — operates on
Buffer / NumGet / NumPut, not AHK objects
- Interpreter-bound — the bottleneck is AHK loop overhead, not an underlying Win32/native call
- Measurable — worst-case cost exceeds ~100μs (below that, DllCall overhead eats the savings)
What Does NOT Qualify
- AHK built-ins that already call native C —
StrPut, InStr, SubStr, Sort, RegExMatch etc.
- Loops over AHK objects/Maps/Arrays — MCode can't read AHK objects without COM interop
- Functions where the expensive part is a DllCall — GDI+, Win32 API calls. The loop around them is not the bottleneck.
- Anything under ~100μs worst case — DllCall marshaling overhead cancels the gain
What to Look For
NumGet / NumPut inside loops (pixel processing, binary protocol parsing, buffer scanning)
- Byte-by-byte or word-by-word buffer iteration
- Math-heavy loops with no AHK object interaction
- Any loop where removing the body makes it instant (= per-iteration AHK overhead dominates)
Reference
src/gui/icon_alpha.ahk — template for MCode embedding (base64 → CryptStringToBinary → VirtualProtect)
tools/native_benchmark/native_src/icon_alpha.c — reference C source (no CRT, no imports, pure computation)
tools/native_benchmark/ — benchmark harness and native build pipeline
Explore Strategy
Focus on files with buffer/binary operations:
src/gui/gui_paint.ahk — rendering, pixel manipulation
src/core/ — icon extraction, process info, any binary data handling
src/shared/ipc_pipe.ahk — binary pipe protocol parsing
src/pump/ — icon resolution, bitmap processing
- Any file with
NumGet or NumPut usage
Plan Format
For each candidate:
| File |
Function |
Loop Description |
Est. Worst Case |
Qualifies? |
Why |
foo.ahk:42 |
ScanBuffer() |
NumGet loop over 256KB icon bitmap, ~65k iterations |
~65ms |
Yes |
Pure buffer, no AHK objects, scales with icon count |
bar.ahk:100 |
ParseWindows() |
Loop over window array calling WinGetTitle |
~2ms |
No |
Bottleneck is Win32 calls, not AHK loop |
For qualifying candidates, additionally note:
- Whether it fits into an existing MCode module (e.g.,
icon_alpha) or needs a new one
- The C function signature it would need
- Any complication (pointer to AHK string, callback needed, etc.)
Ignore any existing plans — create a fresh one.
1---2name: review-mcode3description: Scan for hot loops over raw buffers that would benefit from MCode (native C) optimization4---5Enter planning mode. Scan the codebase for MCode optimization opportunities. Use parallelism where possible.
6
7MCode replaces AHK-interpreted tight loops with native C machine code embedded as base64. The project already has an MCode pipeline (`tools/native_benchmark/native_src/`) and a working example (`src/gui/icon_alpha.ahk`). Adding a new function to an existing MCode module is low cost — the infrastructure exists.
8
9## What Qualifies
10
11All four must be true:
12
131. **Hot path** — called frequently OR scales with data (per-window, per-pixel, per-byte). Use `query_function_visibility.ps1` to check call frequency — a loop called 1x/session vs 100x/sec changes the MCode ROI. Use `query_callchain.ps1 <funcName> -Reverse` to trace all invocation contexts. Use `query_timers.ps1` to check if the candidate is inside a timer callback (hot path signal).
142. **Pure buffer computation** — operates on `Buffer` / `NumGet` / `NumPut`, not AHK objects
153. **Interpreter-bound** — the bottleneck is AHK loop overhead, not an underlying Win32/native call
164. **Measurable** — worst-case cost exceeds ~100μs (below that, DllCall overhead eats the savings)
17
18## What Does NOT Qualify
19
20- **AHK built-ins that already call native C** — `StrPut`, `InStr`, `SubStr`, `Sort`, `RegExMatch` etc.
21- **Loops over AHK objects/Maps/Arrays** — MCode can't read AHK objects without COM interop
22- **Functions where the expensive part is a DllCall** — GDI+, Win32 API calls. The loop around them is not the bottleneck.
23- **Anything under ~100μs worst case** — DllCall marshaling overhead cancels the gain
24
25## What to Look For
26
27- `NumGet` / `NumPut` inside loops (pixel processing, binary protocol parsing, buffer scanning)
28- Byte-by-byte or word-by-word buffer iteration
29- Math-heavy loops with no AHK object interaction
30- Any loop where removing the body makes it instant (= per-iteration AHK overhead dominates)
31
32## Reference
33
34- `src/gui/icon_alpha.ahk` — template for MCode embedding (base64 → CryptStringToBinary → VirtualProtect)
35- `tools/native_benchmark/native_src/icon_alpha.c` — reference C source (no CRT, no imports, pure computation)
36- `tools/native_benchmark/` — benchmark harness and native build pipeline
37
38## Explore Strategy
39
40Focus on files with buffer/binary operations:
41
42- `src/gui/gui_paint.ahk` — rendering, pixel manipulation
43- `src/core/` — icon extraction, process info, any binary data handling
44- `src/shared/ipc_pipe.ahk` — binary pipe protocol parsing
45- `src/pump/` — icon resolution, bitmap processing
46- Any file with `NumGet` or `NumPut` usage
47
48## Plan Format
49
50For each candidate:
51
52| File | Function | Loop Description | Est. Worst Case | Qualifies? | Why |
53|------|----------|-----------------|----------------|-----------|-----|
54| `foo.ahk:42` | `ScanBuffer()` | NumGet loop over 256KB icon bitmap, ~65k iterations | ~65ms | Yes | Pure buffer, no AHK objects, scales with icon count |
55| `bar.ahk:100` | `ParseWindows()` | Loop over window array calling WinGetTitle | ~2ms | No | Bottleneck is Win32 calls, not AHK loop |
56
57For qualifying candidates, additionally note:
58- Whether it fits into an existing MCode module (e.g., `icon_alpha`) or needs a new one
59- The C function signature it would need
60- Any complication (pointer to AHK string, callback needed, etc.)
61
62Ignore any existing plans — create a fresh one.