Performance

Current reviewed claim and gate: bench/PERFORMANCE.md. Some historical tables below predate the multi-size suite and the Java/Swift ports.

and memory

Every program in this file runs on tychoc, its output checked against a golden. Cross-language *ratios* matter more than absolute times, which depend on the machine.

The generated multi-size suite is bench/RESULTS.md, produced by bench/suite.py; it is the source of record for the size/tier measurements. This page is the analysis and historical context. The generated suite now compares both idiomatic and expert manual-memory rows: on binary, the expert C arena beats Tycho (1.47x at the large GCC run), so the older single-tier tree headline is not a claim against the best manual implementation.

A real program at flat memory

examples/json.ty is a 220-line recursive-descent JSON parser over a recursive Json sum type — real recursion, zero malloc/free/refcount/GC in the source. Parsing 5,000,000 documents in a loop holds at a flat 10 MB: each document's tree is reclaimed when its loop iteration's arena resets. Clean under ASan + LeakSanitizer.

Historical memory snapshot

This memory table predates the Java/Swift ports; the current managed-memory time comparison is in the GC/ARC section below. The older Koka column is kept only as history.

Per-workload timings are in bench/prongB/RESULTS.md. Peak resident memory (MB) — every binary computes the same checksum; lower is better. Figures below are rounded per-round snapshots; the precise log, with wall times and hardware, is that RESULTS file.

On the allocation-heavy tree workloads Tycho uses the least memory of the five — 40% of C's on binary-trees, half on tree-rewrite — with no GC and no reference counting, only lexical arenas and value semantics. Memory is the thesis metric, and it is reached with zero manual management.

Current GC / ARC rows

Six core workload ports are built for OpenJDK 25 (GC) and Swift 6.3.2 (ARC); the service rows below extend the same comparison. Wall time, same outputs, best-of-three:

Tycho is faster than both managed-memory runtimes on every port. Java's JVM baseline makes its peak RSS uninformative for the small rows; the table is a time comparison. Koka results elsewhere in the repository are historical and are no longer the headline managed-memory comparison.

Service-row times (ms; same checksums, best-of-three where the runner batches). This is a single-size snapshot from the dedicated service harness; the three-size generated suite in bench/RESULTS.md is the current source of record.

This snapshot predates the final 2026-10-22 codegen and expert-tier run; use bench/RESULTS.md for current row-level claims. The current generated suite has Tycho faster than C and Rust on latency at the large GCC size.

In the final generated suite, Tycho is faster than Rust on latency at the large GCC size. The earlier Rust loss was tied to the pre-unroll codegen and is no longer the current claim.

Relative service scorecard

This is the same single-size snapshot. bench/RESULTS.md carries the generated three-size version and the core rows.

Tycho / competitor; below 1.00 means Tycho is faster. These are the same service runs above, plus latency and gcscan from their own harnesses. Java/Swift memory is excluded from memory claims because their peak RSS includes the runtime baseline; window int, window string and other rows under 10 ms include process startup and are directional only.

The aggregate is useful but not a claim that every row wins: Tycho loses to The older single-size snapshot above is historical. The generated suite now separates idiomatic and expert tiers; see bench/RESULTS.md for the current losses. Missing cells remain -.

The empty-process floor on this Linux host is <1 ms for Tycho/C/Rust/Go, 11 ms for Java and 1 ms for Swift (make bench-floor). Rows near that floor are not evidence about throughput.

The core seven-row prongB scorecard gives the complementary view (geometric mean over its complete rows): time 0.63x vs C, 0.38x vs Rust, 0.28x vs Go, 0.28x vs Java, 0.11x vs Swift; memory (C/Rust/Go only) 0.80x, 0.74x, 0.28x. The tree rows pull that average below 1.0; the flat rows are the honest controls where C/Rust can win.

Backend sensitivity

Tycho emits C, so a Tycho-vs-C number is only meaningful when both are built by the same backend. The current headline rows use GCC. Re-running the latency harness with CC=clang changes the shape substantially:

Tycho is C-class under GCC but loses to C and Rust under clang; this is a code-generation/backend issue, not a reason to hide the row. Use sh bench/backends.sh for the same-source comparison and report the backend with every number. A clang-specific Tycho codegen fix is a separate target.

Service-row coverage

Y means the row is implemented and run by the service harness; - means it is explicitly unported.

The current generated suite has all six dbquery ports; older tables below record the period when Rust/Java/Swift coverage was still missing.

The service-shaped winagg row (per-window map of growing lists) now runs at 82 ms versus C 97 ms, Rust 176 ms, Go 296 ms, Java 277 ms and Swift 374 ms; peak RSS is 7.7 MB versus C 5.9 MB. It is the row the map/list hash and read-only-borrow work targeted.

Arena internals, measured

The peak-RSS tables above are the memory model's *output*. What the model does underneath — how much it reserves, how much it reuses, where the live set sits — is observable directly: TYCHO_ARENA_STATS=full <program> prints a one-shot summary at exit (runtime/tycho_rt.c@stats_dump): peak live bytes (the working-set high-water), total bump-allocated bytes, the free-list recycle rate, OS-reserved bytes over blocks, the block-pool reuse rate, and a per-function — now per-statement, see below — residency table. At the default 64 KiB block size:

Three things the numbers say that the RSS tables cannot:

1. At scale the model is tight. The big workloads hold their live set within 0.1–1.3% of what they reserve from the OS; the blocks fit the bump almost exactly. The 64 KiB block only shows up as slack on toy programs (a 40 B peak over a 64 KiB block).
2. Free-list recycling is workload-shaped, and now countable. The liveness-driven recycle is zero where the working set is held (interp/json/gcscan/trie — trees stay live), and up to 17% of allocations where loop-carried rebuilds hand dead buffers back (optstr_build, strarr_build, structarr_build, lru). Before the counter existed the only evidence was bench-RSS deltas; the per-workload rate is now an instrumented number.
3. Loop scratch peaks near zero. The per-iteration arena_reset keeps a loop's live bytes at one iteration's worth: loop_scratch bumps 10M allocations and peaks at 40 B. Per-statement attribution shows it: on json, a loop labeled main:loop0 bumps 16.4 MiB across 850k allocs with a 344 B peak — the per-iteration reset, now visible per statement instead of folded into the function total.

Block size is a memory-only knob. TYCHO_BLOCK=<bytes> overrides the 64 KiB default per run (read once at startup). A sweep on the three big workloads:

Peak *live* is identical across sizes — the block size never moves the working set, only the slack (≤4% either way here), and wall time is flat. The 64 KiB default is not retuned.

Speed

Against idiomatic per-node C/Rust allocation, Tycho wins the allocation-heavy tree workloads on time and memory. The generated expert-tier controls change the binary result: an expert C arena is faster than Tycho, while Tycho keeps the memory edge. Tycho trails C and Rust on flat array pipelines (per-element bounds checks, not the memory model). The in-place append (an acc = acc + x loop growing one buffer) is guarded by make bench: ~1.5 MB where the un-optimized path is ~825 MB at the same N, so a 32 MB bound sits firmly between working and broken.

Where it costs

The full loss column, with the idiom for each case, is in docs/internals/value-semantics-limits.md. The short version: pointer-shaped data (graphs, doubly-linked lists) costs more unless you use the flat-pool idiom — hold all nodes in one array and link them by integer index, which is also the cache-friendly layout data-oriented engines choose on purpose. Arenas reclaim at *scope exit*, not incrementally, so a long-lived scope holds its transients until it returns — scope them in an inner function.