Performance

Every number here comes from a script you can run against the npm package. Nothing is extrapolated.

npm install @kanunilabs/datagrid-core
curl -O https://kanunilabs.com/benchmarks/datagrid-pipeline.bench.mjs
node datagrid-pipeline.bench.mjs 1000000

1,000,000 rows × 9 columns, Node 24.14.1, Intel Core i7-11390H (4 cores, laptop). Each figure is the median of three runs; the small numbers are the fastest and slowest run. "First query" is the first timing of each run, which pays for the per-column caches described under Collator ranks and Search elimination. Your machine will differ. The benchmarks page has the chart, the method and what these numbers leave out.

1,000,000 rows

100,000 rows

Where the speed comes from

Columnar encoding. Columns become typed arrays — Float64Array for numbers, dates and booleans; a string dictionary plus Int32Array codes for text. Row objects are never copied to the worker; only the buffers are transferred, which is a zero-copy handover.

Dictionary evaluation. A contains or equality filter on a text column is evaluated against the column's distinct values, then reduced to an integer scan. Work scales with cardinality, not row count.

Collator ranks. Text sorting compares precomputed integer ranks instead of calling Intl.Collator inside the comparator. Most of the gap on the text sort comes from this. The ranks are built by sorting the column's distinct values once, and kept until the data changes, so the first sort on a column with many distinct values is much slower than the ones after it.

Radix sort. Numeric sorting uses an LSD radix sort over an order-preserving 64-bit key — eight linear passes with no comparator callbacks at all. A comparator sort of a million rows costs roughly 20 million JS callback invocations; this costs none. Multi-key sorting runs one stable pass per key.

Search elimination. If the search term appears in no dictionary entry of a column, that column is skipped entirely. And since String(someNumber) can only contain a fixed set of characters, a term with letters never scans numeric columns. In the benchmark, a search for "Marmara" scans one column of nine. The lower-cased dictionaries this needs are built by the first search and reused after that.

Quantized scrolling. The virtual window only changes when a row or column boundary is crossed, so most scroll events never reach React at all.

The worker

Above ~20,000 rows the pipeline moves off the main thread. Below that the main thread is genuinely faster — latency beats parallelism for small data.

The worker runs the same pipeline function the main thread would, so results are identical by construction rather than by convention. A suite of golden tests asserts that both paths produce byte-identical row orderings across every operator and data type.

If no Worker global exists (SSR, tests, restrictive environments) or the worker fails to start, the grid degrades to the synchronous path instead of breaking.

Rendering

Rows and columns are both virtualized. A 100,000-row grid keeps ~25 rows in the DOM; columns scrolled out of view are replaced by a single spacer element rather than being rendered.

Measured in a real browser at 100,000 rows: the scroll container reports a 2,800,032 px scroll height while the DOM holds 21–30 row elements, and the rendered block's transform lands exactly on the row grid.

The first-query encode

Before the first sort at large row counts, the grid encodes the columns into typed arrays and transfers them to the worker. That encode has to run on the main thread: it calls your valueGetter and calculateSortValue, and functions cannot be sent to a worker.

The figures in this section come from an earlier measurement on a wider 15-column dataset, not from the 9-column script above. At 100,000 rows the whole pass is 169 ms and unnoticeable. At 1,000,000 rows × 15 columns it is about 3.1 seconds of work — but it is not one 3.1-second freeze. The encode yields to the browser between columns, so the longest single task is one column:

The total work is unchanged — the same rows still have to be read — but the page keeps painting and responding while it happens instead of going white.

Yielding is skipped below 100,000 rows, where the whole encode is a few milliseconds and the scheduling round trip would cost more than it saves.