Benchmarks

Differens compares code structurally instead of line by line. Parsing and matching cost more than git diff’s instant line comparison, but matching is fast: a single linear pass. In return, it reports “renamed” and “moved” where git diff shows a delete/insert pair.

Typical numbers

Measured on an M-series MacBook with bun run apps/cli/bench/bench.ts. Each case runs end to end: parse, match, narrate.

Input	Scale	Time
Small file, one rename	~4k nodes (50 functions)	~19 ms; the first grammar parse dominates
Large file, one rename	~70k nodes (800 functions)	~161 ms
10k siblings, one changed	Flat tree	~4 ms
100k-line file, one line edit	Raw tier	~9 ms, one change
60k-word document, one word edit	Prose tier	~27 ms, one change
20k-line file, fully rewritten	Raw tier	~7 ms, one whole-file Update
200k-node deep chain, full match	Core	~82 ms
3 MiB file, one edit	Raw tier	~6 ms, one change
Monorepo changesets	Hundreds of files	Per-file diffs run on a worker pool sized to your core count; blob reads are batched through one `git cat-file --batch`; `--format=ndjson` streams per-file results as they land

Matching is linear in node count: top-down anchors, bottom-up containers, leaf recovery, all over flat typed arrays. There is no node-count cap and no file-size cap: every input is matched for real. Large text files use a linear-space Myers diff, so a one-line edit in a 100k-line file costs ~9 ms instead of degrading to a whole-file update. Two caches keep repeat work off the hot path. A content-addressed parse cache (64-entry LRU, keyed by content hash and extension) reuses the parse tree whenever the same file content reappears in a run. Repeated identical content short-circuits before any parsing at all.

How to run benchmarks

The benchmark harness lives in the CLI package and is run with Bun:

bun run apps/cli/bench/bench.ts

parse + diff, one small edit (800 functions) .. ~161ms
reorder: first function moved to the end ...... ~39ms
100k-line file, one edit (raw tier) ........... ~9ms
60k-word document, one edit (prose tier) ...... ~27ms
200k-node deep chain, full match .............. ~82ms
3 MiB file, one edit .......................... ~6ms

Compared to git diff

Situation	`git diff`	`differens`
One-line change in a 5k-line file	Instant	Slightly slower (parse + match), but reports the actual change
One-line change in a 100k-line file	Instant	~9 ms, one change
Reformat / whitespace churn	Long noisy hunk	Nothing: no semantic change, no output
Rename of a function	Whole function looks rewritten	One `renamed` action
Function moved between files	Delete + insert	One cross-file `Move`
Generated bundles, lockfiles, vendor blobs	Same hunk cost as anything else	Line-diffed at full size, or one Update when rewritten

For line-level changes on unparseable files, both engines use the same algorithm: a line diff. Differens is the same order of speed.

Fast, slow, being worked on

Fast: structural matching on code and data files, whole-file adds/removals (one action, no tree), same-file moves, batched blob reads, large text files (linear-space Myers), fully rewritten files (one Update), repeat content within a run (parse cache).
Slow: the first parse of a huge file on a cold grammar cache; binary comparisons (hash only, so rarely worth it).
Noted, not needed yet: a persistent cross-run parse cache, SSE output (ndjson covers streaming already).

Getting Started

How It Works

Guides

Benchmarks

Benchmarks

Typical numbers

How to run benchmarks

Compared to git diff

Fast, slow, being worked on

​Benchmarks

​Typical numbers

​How to run benchmarks

​Compared to git diff

​Fast, slow, being worked on

Benchmarks

Typical numbers

How to run benchmarks

Compared to git diff

Fast, slow, being worked on