Home / Benchmarks

Performance, with receipts

Large-file timings need context.

Here is what we have observed, what we have not yet proven, and the protocol that will produce controlled comparisons.

Current observed run

4.3–8.5 sopen 8.0 GB / 50M rows / 15 columns
1.3–2.4 sfilter text across the 8 GB file
1.4–2.5 ssort all 50 million rows
i7 / 32 GB13th Gen Intel, NVMe SSD
Not a controlled comparison. These ranges combine idle runs and runs with development workloads active. They should establish scale, not a leaderboard.

The comparison matrix

The repository now includes a deterministic streaming generator for CSV, TSV and JSONL; canonical sizes from 1 MB through 10 GB; configurable rows, columns, invalid, empty and ragged data; a workload vocabulary; and a tidy raw-result format.

Workloads cover load, string equality, regex, numeric/date ranges, invalid values, string/numeric/date sorts, and grouping with count, sum and distinct aggregation. Command-driven systems are timed automatically. GUI products require a completion signal or recorded manual criterion; process launch alone is not “ready.”

Publication rules

  • Same corpus bytes and recorded SHA-256.
  • Exact product version, OS, CPU, RAM and storage.
  • At least five trials with product order alternated.
  • Cache state declared, never guessed.
  • Median plus spread and every raw valid result.
  • Unsupported operations and failures remain visible.

Why no competitor chart yet?

A fast-looking table with mismatched workloads would be worse than no table. Excel, EmEditor, Modern CSV, DuckDB and csvlite have different readiness signals and semantics. Results will appear here after current builds can be tested under a shared, reviewable protocol.