Tessera Viz

PX-02

Performance

Fast with real data — and you can check it yourself.

A vendor's benchmark is a claim about the vendor's laptop. What follows is the guidance we are prepared to stand behind — which renderer suits which size, and where the honest ceiling is — and a plain statement of what we will publish, and how you will be able to check it, rather than a table of figures you have no way to verify.

The right engine for every data size.

Nodes	Renderer	What you get
Under 2,000	SVG	A DOM element per node. CSS, the inspector and screen readers all work.
2,000 – 20,000	Canvas	One element. Full styling, 60fps interaction.
20,000 – 100,000+	WebGL	GPU-drawn, with the same geometry and styling.
Above ~250,000	Aggregate first	We give you the clustering to do it. We do not pretend the screen has a million useful pixels.

← Swipe for the rest of the table →

← Drag for the rest of the table →

Network layouts, now 16× faster.

What it was doing

Every node repels every other node and every link is a spring, which done naively is O(n²) work per tick. The Barnes–Hut tree that avoids this was already in the codebase; the 2D layout had never called it.

What it does now

A distant cluster is treated as a single mass at its centre, which turns the inner loop from n into log n. The output is the same layout, reached the same way — this is not a different algorithm, it is the same one no longer doing work it could skip.

26.8 seconds to 1.7

Measured on a 2,000-node graph. We publish the measurement rather than the adjective, because "fast" is a claim and a pair of numbers is evidence.

And it widens

Four times the nodes now costs about five times the work, where a quadratic loop charged sixteen. The gap is not a constant you can subtract; it grows with every node you add.

theta, default 0.9

The accuracy dial, and it is a public option. Lower walks further down the tree and is more exact; higher approximates sooner and is faster. The default is ours; the trade is yours.

How to read these numbers.

renderer: auto picks by size

You do not have to know in advance which band a graph falls into. Every layout, every algorithm and every event works identically in all three, so crossing a band changes the renderer and nothing else.

Frame time depends on your data

A heavily decorated graph is slower than a plain one. Density matters as much as count: fifty thousand nodes with four hundred thousand links is a different problem from fifty thousand with sixty thousand.

A baseline, not a promise

These bands are where each renderer stops being the right tool on ordinary hardware. They are not a guarantee about yours, and we would rather say so than be quoted back a number we cannot defend.

Why there is no full table of milliseconds here

Because you could not reproduce most of it yet. Numbers from a vendor you cannot check are numbers you should not trust — including ours. The force-layout figures above are published because they are a before-and-after on the same machine and the same graph, which is a measurement rather than a boast. When the rest of the benchmark runs publicly we will publish it the same way: hardware named, dataset linked, command to run it yourself.

Why it stays fast as your data grows.

One geometry, three renderers

Shape is a set of pure functions all three call. Nothing is computed twice and nothing drifts, so the WebGL path is not a separate implementation that has to be kept in step.

Incremental updates

Add nodes, remove nodes, change properties, and the view animates to the new state rather than redrawing it. A live feed does not cost a full re-layout every time it arrives.

Analysis in the browser

Twenty-six algorithms run over the graph you already have. The round trip you are not making is usually larger than any rendering difference.

Import only what you use

The packages are separate, so a chart-only application never downloads the graph engine. Per-package gzipped sizes are generated by our build rather than written down by hand.