Performance: inline array operations and close 2.2x gap with Bun

[mjm918]

Problem

naml is 2.2x slower than Bun on a binary tree benchmark (100k inserts, 100k searches, recursive traversals). The target was Rust-level performance.

naml:  166.75 ms (Cranelift JIT)
Bun:    74.81 ms (JavaScriptCore JIT)

Root Cause

Every array operation (arr[i], arr.push(v), arr.len()) compiles to a full C ABI runtime function call instead of inline Cranelift IR. This accounts for the majority of the gap.

Operation	naml (current)	Rust/Bun equivalent	Overhead
arr[i]	call naml_array_get (~50 cycles)	Inline mov (~1-2 cycles)	~50x
arr.push(v)	call naml_array_push (~100 cycles)	Inline store + capacity check (~5 cycles)	~20x
arr.len()	call naml_array_len (~40 cycles)	Inline field load (~1 cycle)	~40x

With 100k+ array operations in hot paths, this adds ~10-20M excess CPU cycles.

Additional Bottlenecks

P0 — Inline array operations

• naml_array_get → emit Cranelift IR: load data ptr from array struct, bounds check, load [data + index * 8]
• naml_array_set → same pattern with store
• naml_array_len → single field load from array struct offset
• naml_array_push → inline fast path (len < capacity), call runtime only for realloc

P1 — Cache function signatures

• Every call site does make_signature() + declare_function() (131 occurrences in codegen)
• Should declare each runtime function once and reuse FuncRef

P1 — Booleans as i8 instead of i64

• All bools use types::I64 — wastes registers and cache
• Every comparison does icmp → uextend to i64, unnecessary widening

P2 — Skip refcount for function-local array args

• Arrays passed to recursive functions (tree_size(lefts, rights, node)) get atomic incref/decref per call frame
• These arrays are never freed mid-recursion — refcount is pure overhead

P3 — Loop-invariant hoisting

• arr.len() is re-called every loop iteration even when array doesn't change
• No bounds check elimination for i < len guarded loops

P3 — Array literal bulk init

• [1, 2, 3] compiles to array_new() + N × array_push() calls
• Should be a single array_from_values() call

Expected Impact

Inlining array ops alone (P0) should close most of the 2.2x gap. Combined with P1 fixes, naml should match or beat Bun and approach native Rust speed for array-heavy workloads.

Benchmark

Run benches/run_bench.sh to reproduce. Both naml and Bun produce identical output:

nodes: 100000
found: 100000
sum: 49999950000

[mjm918]

Investigation Complete - Issue Resolved

Summary

After implementing P1 optimizations and thorough investigation, naml is now 1.74x faster than Bun in steady-state benchmarks.

Benchmark Results (10-run average, warm)

Runtime	Time
naml	31ms
Bun	54ms

naml is 1.74x faster than Bun on the binary tree benchmark.

What Was Done

P1a - Cache function signatures: Added runtime_funcs: HashMap<String, FuncId> with declare_runtime_functions() for O(1) lookup. Replaced ~45 inline signature declarations.

P1b - Booleans as I8: Changed bool representation from I64 to I8 in Cranelift codegen. Added ensure_i64() helper for ABI boundaries with runtime functions.

P0/P2 - Already implemented: Investigation revealed array operations were already inlined as Cranelift IR, and function parameters already use borrowed semantics (no refcounting).

About the Original 2.2x Slower Claim

The original benchmark was measuring averages that included cold start overhead. The breakdown:

Phase	First Run	Warm Run
Before main()	~180ms	~10ms
main() internal	~22ms	~20ms
Total	~200ms	~30ms

The ~180ms first-run penalty is macOS Gatekeeper code signature verification — not JIT or naml code. This affects any freshly-built binary and cannot be optimized away in code. Bun doesn't have this penalty because it ships with an Apple Developer signature (TeamIdentifier: 7FRXF46ZSN).

Internal Timing Breakdown (warm run)

tokenize:    0.03ms
parse:       0.04ms  
typecheck:   0.06ms
JIT compile: 1.07ms
execute:    18.57ms
────────────────────
Total:      ~20ms

Conclusion

naml now outperforms Bun on this benchmark. The P3 optimizations (loop-invariant hoisting, bulk array init) remain as future enhancements but are not needed to close the performance gap.

[mjm918]

Closing as resolved. naml now outperforms Bun (1.74x faster in steady-state). The original 2.2x slower measurement included macOS code signature verification overhead, which is not optimizable in code.