[SAOC 2026] CTFE Performance Weekly Update #1

[Abul Hossain Khan]

Hi everyone,

I am working on DMD's CTFE performance for SAOC this year, again 
under the mentorship of Dennis. The plan is to first put the CTFE 
interpreter behind a clean interface so different engine can be 
plugged in and tested. Here is what I did in the first week.

#### Reading the entrypoints

I went through every place the frontend calls into the 
interpreter. Here is my analysis so far:

- 78 `ctfeInterpret()` call sites in 19 files. 25 want an 
integer, 5 a string, 3 a bool. But 26 store the result straight 
into the AST (enum values, initializers etc.), so they need an 
`Expression` back.
- 28 sites don't check for errors after the call at all. It works 
cause the interpreter bumps `global.errors` and the compile fails 
later anyway. 10 of them call `toInteger()` on a possible 
`ErrorExp`, which silently returns 0.
- The interpreter calls back into semantic while it's running, 
and that can start a nested CTFE.

#### Benchmarks

Dennis has a prototype (`-preview=ctfeLinearMemory`) that stores 
CTFE values in flat memory instead of AST nodes. I rebased it 
onto master locally, built master and the branch with PGO+LTO, 
and ran his benchmark cases plus `std.regex -unittest` Multiple 
times.

| case | master ms | linear ms | Δ time | master MiB | linear MiB 
| Δ RSS |
|---|--:|--:|--:|--:|--:|--:|
| deep_calls | 78 | 118 | +51% | 19 | 22 | +16% |
| int_loop | 198 | 199 | +1% | 48 | 20 | -58% |
| sort_array | 257 | 258 | 0% | 65 | 23 | -65% |
| string_build | 109 | 56 | -49% | 132 | 25 | -81% |
| struct_array | 98 | 105 | +7% | 48 | 25 | -48% |
| std.regex | 4678 | 5405 | +16% | 1712 | 878 | -49% |

Memory matches what Dennis measured almost exactly, peak RSS 
roughly halves everywhere except deep_calls. His numbers are here 
- 
https://github.com/dkorpel/dmd/tree/ctfe-linear-memory/compiler/test/benchmark/ctfe#results-with--previewctfelinearmemory

Time is a different story though. His was -35% on int_loop and 
-20% on sort_array, I get parity on both, and std.regex is 16% 
slower. This could be because of different machine configuration.

#### What's next

- In my next meeting with Dennis we will discuss this stuff and 
then figure out what to do next up.
- Add a CTFE heavy workload to the perf bot.

Thanks to Dennis for mentoring this. And as always, feel free to 
leave any feedback or suggestions!