Great job and thank you

[Ben137KBC]

We have some software that was using RapidJSON, and while nothing beats the speed, RapidJSON is not being maintained and no work is done on it all, for years. Sadly there are some CVE's in it, so we were forced to do something. After comparing libraries, we picked nlohmann json. AI was able to convert the code over surprisingly well. And while it is not nearly as fast (where we uses it performance is not critical), we love that it is one file, we had no issues or conflicts bringing it into our code, and it provides a lot of flexibility. We considered simdjson and would have picked it, but it can't serialize or write json. The next best general purpose tool (if you are not using boost which appears would be a great option speedwise), is this nlohmann.

I am curious about the speed differences. I think simdjson and rapidjson use special techniques to parse insanely fast, and while nlohman is much slower, maybe it is not SLOW slow? It uses std classes and I know some of them are very inefficient.

I am curious what you all think about this.

[nlohmann]

On the speed question: yes, nlohmann/json is meaningfully slower than RapidJSON or simdjson, and that's a deliberate trade-off rather than an accident of implementation:

• Design goal. The library is built for usability and standards conformance first (STL-like container interface, implicit conversions to/from your own types via to_json/from_json, iterators, exceptions for error handling, etc.), not for being the fastest parser. That's stated in the README and is the reason it stays a single header you can drop into a project with zero build-system integration.
• Value representation. basic_json stores every value as a tagged union with its own heap-allocated container (std::map for objects, std::vector for arrays, std::string for strings) rather than an arena/pool. Every nested object or array is its own allocation. RapidJSON's MemoryPoolAllocator (and its in-situ parsing mode) avoids most of that per-node allocation cost, which is a big part of the gap.
• Parsing style. The default parser builds the full DOM eagerly and does full UTF-8 validation and number-format checking as it goes. simdjson gets its speed from a very different approach (SIMD-accelerated structural indexing, lazy/on-demand access into a read-only view) that isn't a "make the existing DOM builder faster" kind of optimization — it's a different architecture, and notably (as you point out) it doesn't do serialization.
• std containers. std::string/std::map/std::vector are fine but not free; e.g. std::map (used for objects, to keep keys sorted for canonical output) is pointer-chasing where a flat/sorted-vector map would be more cache-friendly.

None of that is "SLOW slow" for typical workloads — for a lot of applications (config files, REST payloads, logs) the parser is nowhere near the bottleneck, and the ergonomics win out. But if you're in a hot path, there are a few knobs before you'd need to drop the library entirely:

• Use the binary formats (BSON, CBOR, MessagePack, UBJSON) via json::to_cbor/from_cbor etc. — smaller and faster to (de)serialize than text JSON when both ends are your own code.
• Use the SAX interface if you don't need a DOM at all, to skip building basic_json nodes you'd immediately consume.
• Parse with allow_exceptions = false and check json::accept/error codes instead of throwing, if exceptions overhead matters on your error paths.
• If you really need simdjson-level parse speed and our API, some users parse with simdjson and convert the result into a nlohmann::json only for the parts they need to manipulate/serialize with this library.

If you have a concrete benchmark where the gap is a real problem, feel free to share it — profiling a specific case is a lot more actionable than "it's slower."

(Text supported by Claude Code)