Performance

Parlance is built for a game of 500,000 to a million words. Every project that actually exists is three orders of magnitude smaller than that: the demo is 2,700 words, and parlance-monte-cristo — the largest real Parlance project anywhere — is 5,500.

So for most of the tool's life its behaviour at the size it was designed for had been reasoned about rather than measured. This page is the measurement.

Every core operation, from 2.7k to 2M words

Two real projects and six synthetic ones. The synthetic fixtures are produced by inflating a real project while preserving its shape — prose comes from a bigram model trained on the source text, so vocabulary and word-frequency distribution survive, which is what makes the search timings mean anything. Every fixture is a valid project: both validators accept it with zero issues.

The shape matters more than any single figure: everything is linear. Validation holds at 1.31–1.44 microseconds per word across a 46× range in project size. There is no quadratic path waiting at scale — a project twice the size costs twice as much, not four times.

That is the reassuring half, and it is the half worth trusting. The absolute milliseconds are one machine on one day.

Validation does not run inside a save

The actionable half of those numbers: validation is a whole-project pass, so its cost is proportional to the project. It used to run synchronously inside every save, with the response blocked on the result — which meant that at a million words, every save cost the author more than two seconds.

It is now scheduled and incremental. A save returns as soon as the bytes reach disk; a moment later the fresh issue set arrives over the validation WebSocket, and rapid saves coalesce into one pass instead of one each. That pass re-checks only the entities you changed and the ones that reference them, on a worker thread off the editor's main loop — so the cost of a keystroke no longer scales with the whole project the way the table above does. The full whole-project pass still runs when a project loads and whenever a panel needs a guaranteed-fresh answer.

Two things follow, and both are deliberate:

• The panels that answer "what is wrong right now" are never stale. The validation bar and the Reports panel force any pending pass to complete before they reply. Fixing an error and still seeing it would be a worse failure than a slow save, so those routes do not take the shortcut.
• A save's own response reports what was last known. It cannot report otherwise without running the pass it just avoided. The WebSocket corrects the panel within a fraction of a second.

What this means for a project of your size

• Up to ~50k words — everything is instant; there is nothing to think about.
• ~100k words — a blocking save would have cost 223 ms, around the threshold where typing starts to feel sticky. This is where the change starts to matter.
• 500k–1M words — the design target. A blocking save would be 0.7–2.1 seconds, which is unusable; scheduled, it is 1 ms.
• 2M words — twice the top of the target, and still linear: validation 2.9 s in the background, serialization 235 ms, search 42 ms.
• A single enormous dialogue is the one exception. An incremental save re-checks the edited entity in full, so one 5,000-node chapter costs more per edit than the same nodes split across scenes — at that point the project effectively is that dialogue. Splitting a very large dialogue keeps edits snappy.

Reproducing this

The fixtures and benchmarks ship with the editor's source. The generator is deterministic under --seed, so the projects are reproducible even though the timings are not.

Figures above: Apple M3 Pro (11 cores, 18 GB), Node 26, macOS 14.3; every number is a median of repeated runs after a warm-up pass.

If you re-run these, raise the run count before believing a trend. The first pass at this used five runs per operation and produced a convincing superlinear curve for three of them. At fifteen runs most of it evaporated — it was JIT and garbage-collection noise on operations costing tens of milliseconds. Treat the table as a baseline to compare against, not a specification.