nordisk/graph-ar

Native Rust GraphAr: bench and conformance

Date: 2026-11-04. Code: https://www.gunnar.rs/nordisk/graph-ar, harnesses in bench/. Medians per run: raw-summary.md. "Native before" is main cd86afc (upstream layout, ZSTD, before the performance work). "Native after" is main d85f31f (with the performance work: delta-packed integer columns, counting sort, parallel chunk decode).

Headline

Graph: a rustc code graph dump of three Rust workspaces with all their dependencies, 3,421,126 vertices and 4,566,534 edges. Parquet with ZSTD on both sides, median of 5, page cache warm. Reads run on the files the native writer wrote; the C++ reader reads the same files. C++ was run twice with the same binary, once per native version, so the two C++ columns also show the noise of this host.

Where the native crate loses or the result needs a caveat:

• ORC size in these tables: 461 + 55 MB against 16 + 15 MB for C++. The native writer did not compress ORC then; that is fixed, see the update below.
• ORC adjacency to CSR: C++ is faster (146 ms against 181 ms).
• CSV vertex table write: C++ is twice as fast (0.66 s against 1.39 s).
• Peak RSS of read-prop and scan: the native harness holds all decoded batches (183 and 504 MB); the C++ harness drops each chunk (104 and 195 MB). The native reader API returns all batches of a group at once; read_csr is the other way round (83 MB against 159 MB).
• Native multi-chunk reads decode up to 8 chunks in parallel by default; the C++ harness loops over the chunks in one thread of its own (Arrow may use its own pool inside). The serial numbers are below.
• Build: a clean cargo build --release takes 100 s for the native crate (it compiles arrow-rs and object_store) and 40 s for graphar-rs (GraphAr C++ only, Arrow C++ comes prebuilt from apt). The native crate needs no Arrow C++ packages and no C++ compiler, but it is not the faster build. Both with -j 8, on the loaded host.
• The native crate is not C-free: zstd-sys and aws-lc-sys are compiled by cc.
• graphar-rs 0.1.0 only has the vertex row builder, so it appears in one row.

Serial decode (same files, BENCH_THREADS)

Native after (2d757cb) against C++ on the native-written Parquet graph, median of 5:

Point lookup (native only)

EdgeReader::neighbors reads one row window instead of a whole chunk. On a synthetic graph of 10M edges and 1M vertices it went from 59 ms to 26 µs per query (docs/perf.md). This is the crate's own stage bench, not compared with C++.

Peak RSS (code graph, Parquet)

Bytes on disk (vertices + edges, code graph)

The C++ writers write Parquet uncompressed unless WriterOptions are passed, so the harness passes ZSTD. The "after" Parquet files are 63 % smaller than the C++ ones because the native writer uses DELTA_BINARY_PACKED for the integer columns; C++ reads them with the same answers.

Update: value types and ORC compression (cd4e15e)

Added after the runs above: list<T> for every scalar type, date and timestamp values in the row builders, ZSTD ORC chunks.

ORC size. The cause was compression alone: orc-rust compresses only when asked (with_compression), and the crate did not ask. The C++ files were ZSTD (the postscript of a chunk says compression kind 5), so the two sizes were not comparable. Stripe and encoding settings were not the cause: the 16 MB against 461 MB is compression, because orc-rust's direct string encoding with ZSTD ends up as small as the C++ one. Both remaining limits are in orc-rust 0.9: no dictionary encoding for strings, and no list encoder, so writing list<T> to ORC is an error here (create_encoder would panic, the crate refuses first). Reading C++-written ORC lists works.

Second host (see Method), with a newer dump of the same kind of graph: 3,124,200 vertices and 4,172,961 edges. Median of 5, load 28 to 60, native and C++ on the same files:

C++ is still a little ahead on ORC adjacency to CSR (within the noise of this host). Every reader and writer agreed on all of these, and the C++ table writer did not fail in the 10 timed runs here.

Value types. bench/types.sh writes a generated graph (a column of each type, about one value in seven null, lists of 0 to 3 items, date, timestamp and list<double> edge properties) and ldbc_sample_with_feature, then scans with both readers. The sums cover values, not only counts: integers, days and milliseconds by value, floats by their bits, strings by length, lists by length and items.

Each "same sums" cell was read by both readers. The C++ row builders were not part of this check. C++ names five list types (list<int32>, int64, float, double, string); this crate also accepts lists of bool, date and timestamp, which C++ will not load.

Other formats (code graph)

CSV:

ORC:

Arrow IPC (native only, not in the upstream FileType set):

The C++ CSV full scan is - because it fails, see finding 5.

Upstream sample data

ldbc_sample from the testing submodule, 903 vertices and 6,626 edges. Rewritten by each writer (Parquet):

The files as they are in testing (written by Spark), read by both:

These sizes are too small to say anything about throughput: the C++ numbers are mostly fixed setup cost. They are here so the run can be repeated with public data.

Interoperability

Every reader read the graphs of every table writer, and the Spark-written sample. A read reports counts and sums (rows, CSR offsets and indices, column sums).

CSV scan differs only in the C++ reader, on files of every writer: on ldbc_sample the string sum is 2 bytes per edge longer, on the code graph it fails (findings 5 and 6). The native reader gives the same sums on CSV as on Parquet. Info files written by the native crate load in C++.

Conformance (bench/rust: graphar-bench conform testing)

Every *.graph.yml in testing (commit 8286724): all vertex types merged, all adjacency lists to CSR, all edge property groups. Rerun at cd4e15e.

What the crate does not support yet:

Findings in the C++ library

1. AdjListOffsetArrowChunkReader::GetChunk() returns ->column(0)->chunk(0), the first Arrow chunk only (chunk_reader.cc:826). At the default vertex chunk size the offsets of a Parquet chunk come back truncated: n was 1,717,177 instead of 3,421,126. The harness seeks forward to get them all.
2. VertexPropertyArrowChunkReader::GetChunk() with AUTO takes the Parquet-only V2 path when there is no filter, so CSV and ORC fail with "Parquet magic bytes not found". The harness passes V1.
3. Without WriterOptions the writers write Parquet uncompressed, although ParquetOption::compression defaults to ZSTD.
4. The table write path failed with "Cancelled: Plan was cancelled early" in 7 of 60 timed runs, on both datasets and several formats (lines 245 and 247 of the harness: SortAndWriteAdjListTable, SortAndWritePropertyTable). The cause is not known; that host was loaded. It did not happen in the 10 timed runs on the second host. Medians use the successful runs.
5. CSV chunks are read with inferred types, not the declared ones: start_line (null for the first rows of a chunk) fails with "CSV conversion error to null".
6. Same cause, probably: on ldbc_sample a string creationDate that looks like a timestamp comes back 2 bytes longer. Arrow infers a timestamp; we did not inspect the value after GraphAr's cast.
7. The table writer pads the last offset chunk to chunk_size + 1 rows; Spark writes vertex_count + 1. The native reader accepts both.
8. The YAML reader rejects prefix: '' and block sequences that are not indented. The native crate now writes the upstream style.
9. GraphAr C++ at 06dddb1 does not build against Arrow 22 (ReadTable API) and did not link against the Arrow 26.0.1 apt packages (undefined arrow::fs::InitializeS3). We used Arrow 24.0.0.

Method

The large graph is not public; ldbc_sample is what others can repeat at once. Any graph can be used through prep-gar.

Reproduce

See bench/README.md. In short:

git clone --recurse-submodules ssh://anonymous@git.gunnar.rs:2222/nordisk/graph-ar
cd graph-ar/bench
podman build -t graphar-bench -f Containerfile .
# inside the container: build GraphAr C++, gar_bench_cpp, graphar-bench, graphar-rs-bench (README)
LD_LIBRARY_PATH=$PWD/install/lib UPSTREAM_TESTING=$UP/testing RUNS=5 ./run.sh $PWD/work after
python3 summarize.py work/raw/after.jsonl

Medians of every case: raw-summary.md. The one-JSON-line-per-run files stay outside the repository.

CI: .github/workflows/rust.yml has not run on a hosted runner; there is none for this repository, so its steps were run by hand in containers.