Performance

Performance — C League, No Surprises

19 July 2026 · MELP v1.0 · Intel Core i7-10750H · Linux x86-64

What we claim, and what we don't. MELP does not claim to be "faster than C". Its goal is measurable, surprise-free, C-league performance — the same asymptotic class with a known constant difference. MELP is compiled with LLVM/clang, so the fairest comparison is C compiled with the same backend (clang -O2) — which leaves the language itself as the only variable.

Protocol — so it can be audited

Machine	Intel Core i7-10750H @ 2.60 GHz · 12 threads · Linux x86-64
Compilers	MELP v1.0 · clang 22.1.8 (-O2) · gcc 14.2 (-O2) · rustc 1.93.0 (-O) · go 1.25.7
Method	Each test was run 5 times and the best value reported (eliminating cold-start noise). All languages on the same machine, in the same session.
Fairness	Every language's source is open in the repository (`benchmark/.{mlp,c,rs,go}`). The C reference is idiomatic — `string100k.c`, for instance, keeps the length in a variable; it is not* a straw man calling `strlen` on every iteration.

Run time (ms) — lower is better

fib(40) recursive Fibonacci — cannot be folded away, real CPU work

C (clang -O2)

232 ms

MELP

234 ms

Rust (-O)

277 ms

429 ms

How to read it: MELP and C are practically identical (234 ≈ 232) — with the same LLVM backend, the language layer introduces no measurable loss. That is what this chart actually says. MELP also came out ahead of Rust and Go on this test; that is a one-line result, not a headline.

Footnote: the same C source compiled with gcc -O2 runs in 171 ms. That shows gcc's code generation for this recursion pattern is better than LLVM's — a difference between backends, not between languages. It is precisely why clang is used in the comparison table.

string concat 100K 100 000 concatenations — complexity-class verification

C / Rust

~1 ms

MELP

9 ms

378 ms

How to read it: MELP is in the same complexity class as C and Rust — O(n). C and Rust lead on the constant factor (~9×). This is a known and accepted difference; this same test previously behaved as O(n²) and took 1758 ms.

What does not go in the speed table

loop 100M an optimisability indicator — not a speed measurement

An empty 100-million-iteration loop with no side effects is folded away by LLVM at compile time (induction variable elimination) — that is, the loop never runs. The "2 ms" such a test produces measures not CPU speed but how aggressive dead-code elimination is. That MELP's IR is clean enough for LLVM to fold is a good sign; but it is not a speed result and it is excluded from the comparison table. Because the same loop is not folded by GCC, the enormous apparent gap once led to a false conclusion along the lines of "MELP is 65× faster than C".

Run Your Own

The benchmark sources are open in the repository — you can run the same tests on your own machine.

Install GitHub →