Choosing a renderer

How ferrigura stands next to other renderers of Mermaid's syntax. Each project has a page of its own: what it is, how it differs from ferrigura, and what ferrigura can learn from it. This page holds the overview and the measurements. Facts are from each project's documentation and sources at the version named, as of 2026-10-24; measured values say how they were measured.

Overview

The sizes are not alike: ferrigura's is a native library for one platform, with its text engine and 1.4 MB of fonts, where Mermaid and Pele are JavaScript that the browser brings the rest to. merman and mermaid-rs-renderer are not measured here yet: their facts are from their documentation and sources, and the benchmark below runs on JavaScript and the Node addon.

Render time

Measured with tools/port/compare-bench.ts on the 215 pr-check fixtures of the 25 types all three render: each time is the median of 30 renders of one fixture (10 for Mermaid) after a warm-up. ferrigura ran through its Node addon (release build) in two ways: render, which takes the configuration with each call, and a Renderer made once for the configuration and reused for every render. Pele ran in Node (with its width table) and in Chromium (with the canvas), Mermaid in Chromium with its defaults. Every fixture rendered with all three. Machine: Apple M1 Ultra, macOS 27.0.1, Node 24.22.0, Chromium 151.0.7922.34. Run of 2026-10-24, with ferrigura 0.2.0, Pele 1.9.0 and Mermaid 12.2.0; two runs earlier that night, under the load of a backup, gave ferrigura medians up to 0.84 ms and left Pele and Mermaid where they are.

The two ferrigura columns are the same now: the shorthand's cache of the resolved configuration costs no more than a Renderer made once (on 2026-10-18, render took 0.73 ms for a fixture without configuration, against 0.34 ms for the Renderer). Of the 215 fixtures, 103 carry a directive or a configuration block, which each render merges on top of the resolved configuration, as the decision keeps: 0.93 ms in the median. The other 112 use the resolved configuration as it is: 0.37 ms. Against the run of 2026-10-18, before the P3 types, the swimlanes and the emoji face came in, the median rose from 0.66 to 0.70 ms and the 90th percentile from 1.61 to 2.01 ms, the state diagrams the most (1.60 to 2.13 ms); what costs the difference is not measured.

¹ Chromium's timer resolution is 0.1 ms on a page that is not cross-origin isolated, which is below what Pele needs.

The median per type, in milliseconds:

The work is not the same either: ferrigura embeds a font subset and reproduces Mermaid's layout, Mermaid lays out and measures in the page, and Pele in Node estimates text widths and draws a simpler layout.

Where the time goes

A CPU profile of each shows where the time goes (profiles of 2026-10-17 and 2026-10-18). In Mermaid, and in ferrigura before step 2 of decision 0008, much of the time went to the configuration, not to drawing:

• Mermaid (Chromium's profiler, 475 renders of the pr-check fixtures of ten types): 57 percent of the time is in assignWithDepth, the deep merge that getConfig() runs to hand out a fresh copy of the whole configuration, theme variables included, every time a renderer, shape or label asks for it. Then ELK and the other layouts (17 percent), DOMPurify (10), style and layout work of the browser (6), and the DOM measurement (getBBox() and the like, with the layout it forces: 4). So measuring text with a canvas, as Pele does, would save Mermaid a few percent; handing out the configuration without a deep copy per call would save more than half.
• ferrigura (macOS sample, 12 seconds of small pie renders through one Renderer, 0.13 ms each, with no directive): the configuration no longer shows in the profile. Before step 2, 63 percent of the time of such a render was in prepare, which merged the layers (effective) and read the typed view (typed) on every call. The render now takes the resolved configuration as it is, and about half of its samples are in the text crate, embedding the subset of the bundled faces that the labels use (the skera subsetter), which each SVG needs to be self-contained. A text with a directive or a configuration block still merges it on top in each render. In a profile of one such flowchart, prepare took 47 percent of the render, most of it in the typed view of the merged configuration (typed, the lenient reader and serde) and in the layers (effective). That is the next cost to take, with the typed sections of decision 0008, step 3. Step 3 is done since 2026-10-19 (issue #4); its effect is not measured here.
• Pele was not profiled here. It has no DOM, no theme to compute and no configuration of that size to merge (its page), which is where the other two spend their time.

Adding a comparison

Add a page named after the project with the sections of the others (what it is, how it differs from ferrigura, what ferrigura can learn from it), a row in the table at the top and a column in the overview, and run the benchmark with it when it can render the same fixtures. Name the version and the date of every fact.