A Rust benchmark build leaves the C++ decision open
simdjson's speed claims need a workload measurement that our recorded run does not supply. On September 25, 2026, our harness selected the Rust crate at benchmark/static_reflect/serde-benchmark/, at commit 23b236d6e713691e3de43ca3452394b2e230daf4. That distinction determines what this review can conclude.
The README describes a C++ library using SIMD instructions and microparallel algorithms, with On-Demand as its default front end. It claims parsing speeds over four times those of commonly used production parsers. Those are project claims, not results reproduced here.
For a C++ team, the useful next question is whether simdjson improves the work the application actually performs, including input preparation and value extraction.
What our recorded run established
The recorded environment had 3 CPUs, 12 GB of memory, and image label lab-rust:1. That label does not establish an actual Rust compiler version.
| Step | Recorded observation | Limit |
|---|---|---|
| Dependency download | Exit 0 in 952 ms; stored summary: 1 second and 15 dependencies | This does not prove a simdjson executable was installed |
| Build | Exit 0 in 7,113 ms; stored summary: 7 seconds | The log identifies serde-benchmark v0.1.0, built in an unoptimized development profile |
cargo test |
Exit 0 in 1,356 ms; stored summary: 1 second | The visible lib.rs and src/main.rs unit-test invocations each report running 0 tests |
The stored test aggregates are 0 passed, 0 failed, and 0 total. The captured output repeats summaries after a replay marker, and unique, exhaustive counts were not verified. We therefore draw no suite-count or parser-correctness conclusion from those aggregates. The command completed successfully, but the visible invocations supplied no substantive tests.
The logs also contain warnings about an unspecified Rust edition and extern declarations without an explicit ABI. Neither prevented the recorded build. They do not establish a defect in the C++ parser.
The checkout measurements were 773 files, approximately 119,390 source lines, and 34.2 MB. The scan recorded 44 CI workflow files and a tests directory. These describe the checkout, not deployed library size, executed CI coverage, or application memory use. No audit result or advisory coverage was recorded.
We did not execute the C++ quick start, check an installed binary, exercise CPU dispatch, validate input-buffer behavior, or measure parsing throughput.
The documented C++ setup is a separate path
The README documents integration through simdjson.h and simdjson.cpp. Its command-line quick start calls for g++ 7 or better or clang++ 6 or better and a 64-bit system. It notes separate steps for Visual Studio and Xcode and says clang++ users may need to select a C++ language version explicitly.
The README also says the library selects a CPU-tailored parser at runtime and recommends working from a release when using simdjson in a product. These are documented capabilities and recommendations, not checks completed by our Rust run.
The performance guide recommends reusing parsers because internal buffers persist between parses. It also discusses input padding and recommends defining NDEBUG for release builds once application code has been tested. Its warning about floating-point-heavy documents is useful: number conversion can dominate processing, so a headline throughput figure is a poor substitute for your own corpus.
The supplied basics-guide capture contains GitHub navigation and file metadata rather than its API text. This review therefore does not use it to substantiate detailed lifetime, invalidation, or DOM behavior. Check the documentation matching your selected release before designing around those rules.
Release and feature evidence need their own scope
The v4.6.11 release notes list six audit findings reproduced on 4.6.10. They cover scalar handling at a parse_many window boundary, a zero-depth allocation case, source-view lengths across batches, a fallback UTF-8 boundary case, capacity overflow guards, and allocation-failure state. These are upstream release findings. Our run did not reproduce them or verify their fixes.
The UTF-8 entry specifically says the described over-read was not reachable through a public API on 4.6.x; its observable defect was rejection of a valid NDJSON stream at a window edge. The release notes do not justify treating every listed item as an independently demonstrated security vulnerability. They also do not establish that v4.6.11 remains the latest release. The supplied current README refers to examples using simdjson 5.0.1, while our measurement remains tied to the September commit.
Issue 2070 remains open and describes JSONPath support as strictly limited to a subset convertible to JSON Pointer. If full JSONPath is a requirement, verify the exact expressions you need before adopting the library.
Issue 1020 is closed. On September 29, 2026, the maintainer closed it with a link to a compressed-input demonstration. The issue's original 2020 description of fully decompressing a document first cannot establish a current blanket limitation. We did not inspect or run the linked demonstration, so this review makes no claim about its formats, throughput, or integration into the core library.
Choose a comparison that fits your code
The supplied yyjson README describes an ANSI C library whose parsing results are immutable and require a mutable copy for modification. It is a relevant comparison when a C interface and explicit document manipulation suit the application.
JSON for Modern C++ emphasizes intuitive syntax, a single C++11 header, and STL-like access. It is a relevant comparison when those integration and programming choices matter to your team. Its README acknowledges that faster JSON libraries exist; that statement does not quantify a difference for your workload.
This review has no comparative benchmark result. Use the same documents, correctness checks, extracted values, and deployment CPU for each candidate. Include allocation and decompression when they are part of the application path, and distinguish cold setup from repeated parsing.
How to read the scores
These are editorial assessments of the supplied evidence, not benchmark results. The scale is 1 for substantial documented obstacles, 2 for limited evidence, 3 for a documented evaluation path with material checks remaining, 4 for detailed support within the assessed scope, and 5 for strong support across that scope. Unknown adoption and untested compatibility do not earn a high score.
Setup receives 3 because the C++ entry path is documented but was not executed here. Documentation receives 3 because the README and performance guide are useful, while the supplied basics capture does not expose its API text. Community receives 2 because the extracts show maintainer participation but do not establish adoption or support responsiveness. Maturity receives 3 because the release notes document concrete defect review, while this run supplies no C++ correctness or deployment evidence.
Start with a selected release and its C++ example. Proceed to an application comparison only after that path builds and produces the expected result in your environment.