Hacker News Reader

Hacker News

Comment by einpoklum | Hacker News Reader

Parent Full thread

einpoklum

How does this compare with RapidJSON, JSONCpp and JSON Spirit - other popular C++ JSON parser libraries?

Links:

http://rapidjson.org/ https://github.com/Tencent/rapidjson

https://github.com/open-source-parsers/jsoncpp

https://www.codeproject.com/Articles/20027/JSON-Spirit-A-C-J...

View on HN

We used to use. We first micro-benchmarked all those and we found that Tencent/rapidjson was more than 100% faster than nlohmann/json :)

Our primary use is to parse http://cocodataset.org/ metadata files and RapidJson is 100% faster.

RapidJson is very efficient. I have used several JSON libraries for C++, and right now I'm really enjoying json_dto, which is built on RapidJson. It has great developer UX, including the most succint syntax I've used, and support for std::optional.

https://github.com/Stiffstream/json_dto

> 100% faster.

So, twice as fast - it parses the dataset in half the time?

On the other hand, nlohmann/json has a cleaner and more Python-like API, so if you don't care about performance that much, I'd say it's the way to go

Does anyone write C++ and not care about performance?

We use C++ and care about real time performance, but also use this JSON library, the thing is that we use JSON for loading and configuring data which happens during load time which is infrequent and don’t need JSON during the critical update path.

Previously we used rapid json which is faster but the syntax of the nlohmann json is nicer and it is much quicker to develop with.. we also use python a lot so the familiarity between the 2 is also useful, some of the other C++ json libs can have quite convoluted api’s for dealing with values, objects and arrays.

On the other hand: I'm a bit surprised at how many people are writing JSON and care about the performance.

The overwhelming majority of our IO is reading / writing data files, but those are stored in an optimized binary format. The configuration / metadata accounts for a much smaller fraction of IO. For this tiny fraction we care about flexibility and readability, a slow JSON parser is fine.

While I agree that in many cases JSON parsing is not the largest consumer of resources, it really sucks when it is.

At some point it seems like a general mindset shifted from making things efficient at every level to assuming things don’t matter if you’re probably doing something worse anyway.

If you use C++ for CPU-intensive tasks, then yes, in this case. E.g. reading 1kb of input, churning numbers for 10 minutes and outputting an h5 file. If you use C++ for IO-intensive tasks, then your tradeoff is probably different and you would optimise your IO for speed and not readability.

If you know you only get small JSON files, e.g. for configuration and so on, then - yes, you might not care about the parser performance and be more interested in the elegance of its API.

This is not a Boolean thing. If I spend a "long" time in processing the data in my business logic the time spent to load the data or storing the result can be neglectable.

If reading/writing is the hot path things are different, though.

First of all absolutely, but more importantly who cares about the performance of your json parsing? I can only think of very few applications where that would be relevant at all, even if you care about performance in general.

You dont necerrarily need to care for everything to be performant.

If that's a configuration file which is read once - yes

This is a very convenient library for getting started. It even has a mode that made it possible for me to parse numbers into a decimal class.

I would point out that its convenience in large part depends on extensive use of cast operators, which can lead to some tricky corner cases. It is also the only component in one of my projects that confuses xlclang++ on AIX.

I switched from rapidjson to this library (nlohmann's) because it is so simple to use and integrates into C++ very cleanly.

If I had enormous globs of JSON to read I might use something faster (I believe there's a very fast library that uses SIMD instructions) but my needs are quite limited: basically exchanging snippets of JSON with a network service. So clarity was far more important than performance.

Reply on news.ycombinator.com