Performance
How fast does text become SVG? The benchmark below renders the same diagram — a chain of N labelled boxes joined by arrows — expressed in each tool’s own language, and times cold CLI invocations (process start to SVG written), which is what a documentation build or CI pipeline actually pays per diagram.
Cold render to SVG — chain of N labelled boxes, median time
| Tool | 5 nodes | 30 nodes | 120 nodes | jitter |
|---|---|---|---|---|
| pikchrC | 1.7 ms | 1.9 ms | 3 ms | ±0.6 |
| dpicC | 2.5 ms | 2.8 ms | 3.7 ms | ±0.6 |
| rpicRust | 4.3 ms | 4.2 ms | 5.3 ms | ±0.8 |
| graphviz dotCauto-layout | 85 ms | 83 ms | 84 ms | ±2.9 |
| d2Goauto-layout | 62 ms | 134 ms | 449 ms | ±9.3 |
| mermaidmmdc · Chromiumauto-layout | 537 ms | 582 ms | 713 ms | ±22.6 |
hyperfine, warmup, median of 10–454 runs · jitter is the 120-node interquartile range (lower = more deterministic) · bars are linear in the 120-node time — the near-invisible pic-family bars are the honest picture · outputs verified complete · reproduce with tools/bench50 small diagrams, rendered in sequence
That ~140× difference in the pipeline scenario is the gap between a site build you don’t notice and one you schedule around.
Point estimates hide the shape of the data, so here is the full distribution at the largest size, on a logarithmic axis — the only honest way to show a field that spans three orders of magnitude:
Render-time distribution — 120-node chain, log axis
hyperfine, 10–454 runs/tool. rpic's IQR is 0.8 ms — the pic family renders in a deterministic hairline; mermaid's box spans ~23 ms.The box widths are the story a single number can’t tell: rpic’s middle 50% of runs fall inside a 0.8 ms window, so its timing is as predictable as it is fast. In the 50-diagram batch mermaid’s total swung from 24 s to 60 s across runs — the headless-Chromium boot is not just slow but variable, which is what makes it painful in a build.
Read the numbers honestly
- rpic sits in the C class. Single-digit milliseconds, essentially flat with diagram size (a ~5.3 ms median at 120 nodes — the cost is process startup, not compilation). The couple of milliseconds above dpic/pikchr is binary size (embedded fonts, the math renderer), not the engine.
- The comparison has a built-in asymmetry. graphviz, d2 and mermaid compute the layout — a genuinely expensive and valuable problem. The pic family delegates placement to the author. These are different value propositions; this page measures pipeline cost, not which tool you should love.
- mermaid’s floor is the browser, not the algorithm.
mmdcboots a headless Chromium per invocation (~540 ms before any diagram work). Embedded in a live page, mermaid.js renders far cheaper — but in CI and static-site builds, the CLI is what runs. - d2’s layout cost grows with size (62 → 449 ms across our range); graphviz is flat but starts near 85 ms.
Why rpic is fast
No system dependencies to shell out to, no VM, no browser: one static
binary parses, evaluates and serializes SVG in a single pass, and the
texlabels math renderer only engages when
a $…$ label exists. The same engine compiled to WebAssembly powers the
playground and the JS binding, so
in-browser rendering needs no server round-trip at all.