neo vs Arrow · library 25.0.1

neo vs Arrow.

The same input and the same kernels, in neo's C++ and in Arrow 25.0.1. Across 10 measurements neo finished 2.29× faster in the middle and 3.89× at most; Arrow was not quicker on any.

01 · The race

One kernel at a time

Each piece of work below has its own race, what it measures, how each side does it, the code that ran and every number taken for it. In a race both ships run for the same stretch: Arrow completes the work once, and neo completes it as many times as the measured ratio says, turning around at each end.

  1. 01.1 · load worldcitiespop2.02×
  2. 01.2 · load NYC taxi · 1M1.72×
  3. 01.3 · load NYC taxi · 10M2.29×
  4. 01.4 · load ClickBench · 1M3.89×
  5. 01.5 · load ClickBench · 10M3.62×

01.1 · public data · a file this project did not make

load worldcitiespop

neo 11.4 ms · Arrow 23.0 ms · 2.02× neo. Against every engine →

neo

Arrow

0 runs

0 runs

What this measures

Read worldcitiespop from its path to a table in memory: 3,173,958 rows by 7 columns, 151 MB of place names, the file the CSV tools benchmark on. Every engine in a fresh process each round, the file in the OS cache, each engine's start-up done before the clock; warm is the median of the loads after the first. neo's table is text, with no types, no nulls and no UTF-8 check, so the rows as text are the like-for-like ones.

How neo does it

The same parser as the synthetic load, on a file this project did not make, checked column by column and row by row against DuckDB's reading of it before any time is taken.

How Arrow does it

PyArrow's CSV reader, asked for every column as a string so that its table is text, as neo's is. Its thread pools are started on a three-line file before the clock.

Arrow reading the public files · neon-cpp/bench/lang/python/standards.py:95
def load_arrow(path, mode, loads, opt=None):
    import pyarrow as pa
    import pyarrow.csv as pc
    convert = pc.ConvertOptions(column_types={n: pa.string() for n in header_names(path)}) if mode == "text" else pc.ConvertOptions()
    parse = pc.ParseOptions(newlines_in_values=True) if opt else pc.ParseOptions()
    pc.read_csv(io.BytesIO(b"a,b\n1,x\n2,y\n"))  # untimed: the reader's own start-up (its thread pools), on three lines that are not the file
    out, rows, cols = [], 0, 0
    for _ in range(loads):
        t0 = time.perf_counter()
        t = pc.read_csv(path, convert_options=convert, parse_options=parse)
        out.append(ms_since(t0))
        rows, cols = t.num_rows, t.num_columns
        del t
    return pa.__version__, out, rows, cols, pa.cpu_count()

neo's side: the call and the contract

the parser's contract · neon-cpp/core/csv.h:55
Table parse(std::string_view raw);  // parallel above 1 MB, serial below; identical results

Every number taken for it

measurementneoArrow× neo
first load, as text, msThe median first load: a fresh process each round, the file in the operating system's cache, the engine's own start-up done before the clock.23.826.31.10×
loads after the first, as text, msThe median of the loads after the first, in the same process.11.423.02.02×

01.2 · public data · a file this project did not make

load NYC taxi · 1M

neo 52.9 ms · Arrow 90.7 ms · 1.72× neo. Against every engine →

neo

Arrow

0 runs

0 runs

What this measures

Read NYC taxi · 1M from its path to a table in memory: 1,000,000 rows by 51 columns, 425 MB of trips. Every engine in a fresh process each round, the file in the OS cache, each engine's start-up done before the clock; warm is the median of the loads after the first. neo's table is text, with no types, no nulls and no UTF-8 check, so the rows as text are the like-for-like ones.

How neo does it

The same parser as the synthetic load, on a file this project did not make, checked column by column and row by row against DuckDB's reading of it before any time is taken.

How Arrow does it

PyArrow's CSV reader, asked for every column as a string so that its table is text, as neo's is. Its thread pools are started on a three-line file before the clock. The reader is the one shown under the first public file.

neo's side: the call and the contract

the parser's contract · neon-cpp/core/csv.h:55
Table parse(std::string_view raw);  // parallel above 1 MB, serial below; identical results

Every number taken for it

measurementneoArrow× neo
first load, as text, msThe median first load: a fresh process each round, the file in the operating system's cache, the engine's own start-up done before the clock.72.996.11.32×
loads after the first, as text, msThe median of the loads after the first, in the same process.52.990.71.72×

01.3 · public data · a file this project did not make

load NYC taxi · 10M

neo 418 ms · Arrow 959 ms · 2.29× neo. Against every engine →

neo

Arrow

0 runs

0 runs

What this measures

Read NYC taxi · 10M from its path to a table in memory: 10,000,000 rows by 51 columns, 4.3 GB of trips. Every engine in a fresh process each round, the file in the OS cache, each engine's start-up done before the clock; warm is the median of the loads after the first. neo's table is text, with no types, no nulls and no UTF-8 check, so the rows as text are the like-for-like ones.

How neo does it

The same parser as the synthetic load, on a file this project did not make, checked column by column and row by row against DuckDB's reading of it before any time is taken.

How Arrow does it

PyArrow's CSV reader, asked for every column as a string so that its table is text, as neo's is. Its thread pools are started on a three-line file before the clock. The reader is the one shown under the first public file.

neo's side: the call and the contract

the parser's contract · neon-cpp/core/csv.h:55
Table parse(std::string_view raw);  // parallel above 1 MB, serial below; identical results

Every number taken for it

measurementneoArrow× neo
first load, as text, msThe median first load: a fresh process each round, the file in the operating system's cache, the engine's own start-up done before the clock.4489542.13×
loads after the first, as text, msThe median of the loads after the first, in the same process.4189592.29×

01.4 · public data · a file this project did not make

load ClickBench · 1M

neo 96.0 ms · Arrow 373 ms · 3.89× neo. Against every engine →

neo

Arrow

0 runs

0 runs

What this measures

Read ClickBench · 1M from its path to a table in memory: 1,000,000 rows by 105 columns, 842 MB of web hits. Every engine in a fresh process each round, the file in the OS cache, each engine's start-up done before the clock; warm is the median of the loads after the first. neo's table is text, with no types, no nulls and no UTF-8 check, so the rows as text are the like-for-like ones.

How neo does it

The same parser as the synthetic load, on a file this project did not make, checked column by column and row by row against DuckDB's reading of it before any time is taken.

How Arrow does it

PyArrow's CSV reader, asked for every column as a string so that its table is text, as neo's is. Its thread pools are started on a three-line file before the clock. The reader is the one shown under the first public file.

neo's side: the call and the contract

the parser's contract · neon-cpp/core/csv.h:55
Table parse(std::string_view raw);  // parallel above 1 MB, serial below; identical results

Every number taken for it

measurementneoArrow× neo
first load, as text, msThe median first load: a fresh process each round, the file in the operating system's cache, the engine's own start-up done before the clock.1263732.95×
loads after the first, as text, msThe median of the loads after the first, in the same process.96.03733.89×

01.5 · public data · a file this project did not make

load ClickBench · 10M

neo 1,056 ms · Arrow 3,829 ms · 3.62× neo. Against every engine →

neo

Arrow

0 runs

0 runs

What this measures

Read ClickBench · 10M from its path to a table in memory: 10,000,000 rows by 105 columns, 8.1 GB of web hits. Every engine in a fresh process each round, the file in the OS cache, each engine's start-up done before the clock; warm is the median of the loads after the first. neo's table is text, with no types, no nulls and no UTF-8 check, so the rows as text are the like-for-like ones.

How neo does it

The same parser as the synthetic load, on a file this project did not make, checked column by column and row by row against DuckDB's reading of it before any time is taken.

How Arrow does it

PyArrow's CSV reader, asked for every column as a string so that its table is text, as neo's is. Its thread pools are started on a three-line file before the clock. The reader is the one shown under the first public file.

neo's side: the call and the contract

the parser's contract · neon-cpp/core/csv.h:55
Table parse(std::string_view raw);  // parallel above 1 MB, serial below; identical results

Every number taken for it

measurementneoArrow× neo
first load, as text, msThe median first load: a fresh process each round, the file in the operating system's cache, the engine's own start-up done before the clock.1,0533,7523.56×
loads after the first, as text, msThe median of the loads after the first, in the same process.1,0563,8293.62×

02 · Every number

Public data, from a path to a table

loads after the first, as text · ms, lower is better · 2026-10-11 16:43

kernelneoArrow× neo
worldcitiespop · first load, as text23.826.31.10×
worldcitiespop · loads after the first, as text11.423.02.02×
NYC taxi · 1M · first load, as text72.996.11.32×
NYC taxi · 1M · loads after the first, as text52.990.71.72×
NYC taxi · 10M · first load, as text4489542.13×
NYC taxi · 10M · loads after the first, as text4189592.29×
ClickBench · 1M · first load, as text1263732.95×
ClickBench · 1M · loads after the first, as text96.03733.89×
ClickBench · 10M · first load, as text1,0533,7523.56×
ClickBench · 10M · loads after the first, as text1,0563,8293.62×

Public CSVs, not ours, from a path to a table in memory, in neo and in engines this project did not write (Arrow 25.0.1, Polars 2.0.0, DuckDB 1.5.6, pandas 3.0.6). Milliseconds. worldcitiespop.csv is the file as xsv, qsv, xan and zsv benchmark it; the taxi and ClickBench files are the first records of the files those benchmarks publish, byte for byte, under a header line made from the benchmark's own schema (scripts/fetch_standards.sh; every source and SHA-256 is in bench/results/standards/manifest.jsonl). Every engine runs in a fresh process each round, in an order shuffled each round: the first row is the median first load, the second the median of the loads after it. The file is in the operating system's cache throughout, and each engine's own start-up is done before its first load, so these are the readers and nothing else. neo goes through the loader the app uses. Its table is text and only text: no types, no nulls (an empty field is an empty string), no check that the bytes are UTF-8, every field trimmed and a line end inside quotes made \n, as the app it replaces did; the others asked for text check UTF-8 and keep nulls. So the first two rows are the like-for-like ones; in the last two the others also infer types, which neo's loader does not do, and neo's numbers there are its text load again. Before any time is taken neo's table is compared with DuckDB's reading of the file, and each card says what came of it. pandas is run with its pyarrow engine. Threads are each engine's default: 18 here for the others; neo 16, and 18 from 256 MB of input, counts that were chosen on this machine. A dash is an engine that did not read the file.

03 · The code that ran

Arrow's side, in full

Apache Arrow's C++ CSV reader, through PyArrow: the reader several other tools use underneath. Its kernels are written the way its users write them. Its code is beside each race above, and nothing of it is left out here.

neo's side: the calls and the contracts

neo's kernels are the product, so their bodies stay in the engine. What is published is what a reader needs to judge the comparison: the harness calling the engine, and each kernel's declaration with the guarantees it is held to, down to the order a floating-point sum is taken in. Each contract is beside its race above; the harness lines together, and whatever no race showed, are here. The binaries run on request, and the scripts named below reproduce every number on this page.

the harness, calling the engine · neon-cpp/bench/bench_engine_options.cpp
 194  l.t = csv::parse(raw);
 337  const double f5 = timeIt([&] { Bitmap b = compareDoubles(amt.data(), n, Cmp::Gt, 500, &pool); sink = b.words[0]; }, 7);
 372  const double s4 = timeIt([&] { sortIndexByDouble(amt.data(), n, perm, &pool); sink = perm[0]; }, 3);
 454  const double a5 = G <= 16 ? timeIt([&] { groupSumAnyOrder(amtP, idP, n, G, &pool, pairTotal); sink = static_cast<size_t>(pairTotal[0]); }, 9) : 0;
the filter's contract · neon-cpp/core/selection.h:1
// selection.h — the result of a filter: one bit per row. 1M rows = 125 KB,
// written at memory speed; indices are produced only when something needs them.

struct Bitmap {
    std::vector<uint64_t> words;
    size_t bits = 0;
    bool test(size_t i) const { return (words[i >> 6] >> (i & 63)) & 1; }
    size_t count() const;
    std::vector<uint32_t> indices() const;  // ascending row indices of the set bits
};

// JS measurefilter semantics: NaN never matches. Sequential below ~1M values; the pool otherwise.
Bitmap compareDoubles(const double* v, size_t n, Cmp op, double threshold, Pool* pool);
the sort's contract · neon-cpp/core/sort.h:1
// sort.h — stable O(n) sorting of row indices by a double key (parallel radix).
// JS numeric sort semantics: NaN sorts as -Infinity; ties keep input order.

// Fills `idx` with the stable ascending order of keys[0..n). pool may be null.
void sortIndexByDouble(const double* keys, size_t n, std::vector<uint32_t>& idx, Pool* pool);
the group sum's contract · neon-cpp/core/groupsum.h:1
// groupsum.h — a typed column's sum, count and extremes per group: what the aggregate node's measures need
// once the column is doubles (toDoubles) and every row has a group number.
//
// The results are the ones a loop over the rows in order gives — `if (isFinite(v)) { sum += v; n++;
// if (v < min) min = v; if (v > max) max = v; }` a group, which is what the JavaScript does — to the bit:
//   • counts and extremes are taken a part of the rows at a time on the pool and the parts joined in row
//     order (a strict comparison keeps the earlier of two equal values, as the loop does);
//   • a sum is added in row order on one thread, because a floating-point sum depends on its order —
//     unless the column is whole numbers small enough that no addition can round (wholeNumbers below),
//     where every order gives the same bits and the rows are summed on the pool, two a step.
// bench/bench_agg_node.cpp times each path against the node and checks it; PHD.md §30.

// The sum alone, any order, two rows a step; for tests and the benchmark (groupStats calls it when it may).
// False, and nothing written, when there are more groups than it is built for.
bool groupSumAnyOrder(const double* x, const uint32_t* id, size_t n, size_t groups, Pool* pool, double* sums);
how energy is read · neon-cpp/bench/energy.h:1
// energy.h — what a process has used, as the operating system's own ledger has it: the energy it was billed,
// its processor time, the wake-ups it caused. The one reader of that ledger, for two questions:
//   what a kernel costs — the Evals page's Energy view (bench_engine_options.cpp reads it around each kernel;
//     tools/energy/energy.cpp checks the counter and reads it for a command it runs;
//     bench/lang/python/yardstick.py reads the same field; PHD.md section 33)
//   what a process costs at rest — the idle studies (scripts/idle_cost.sh and scripts/idle_server.py take
//     `neon_energy --pid <pid>` twice and subtract; PHD.md section 31.1)
//
// macOS on Apple silicon: proc_pid_rusage(RUSAGE_INFO_V6). ri_energy_nj — nanojoules billed to the process's
// threads for the processor cores they ran on, since it started. Not the memory, the disk or the screen, and
// not the machine at rest: what running this code added. (Not ri_billed_energy: against half a second of a
// busy loop that field read 0.08 mJ where ri_energy_nj read 1,887.) Beside it, processor time in nanoseconds
// — `ps` has hundredths of a second, more than a resting window uses in a minute — and the wake-ups. No
// privilege is needed, and any process of the same user can be read, so a tree of processes can be summed.
// Linux: /proc/<pid>/stat and /proc/<pid>/status — clock ticks and context switches. No energy: RAPL is one
// figure for the whole machine and root's to read.
// Elsewhere: nothing is read (ok stays false).
//
// A reading is cumulative; a measurement is the difference of two. The counter moves in steps (a thread's
// share is settled when it leaves a core or enters the kernel), so a window should be a quarter of a second
// or more: `neon_energy --check` prints how far apart the steps are on the machine it runs on.

04 · Diligence

What both sides were held to

Scripts: scripts/bench_standards.sh · measured 2026-10-11 · the numbers on this page come from the same ledger as the app's own Evals page, written by neon-cpp/scripts/results_md.py.

More comparisons