Benchmarks?

[patlecat]

Hi, has anyone done any comparing benchmarks of this new lib that shows how it performs to other JSON C++ libs? Would be great to see that.

[ColinH]

In a nutshell, taoJSON (as we will call it) seems to be (one of) the fastest within the class of libraries based on standard containers. Libraries like RapidJSON that use custom (but generic, in the sense of "can store any JSON") data structures can be a lot faster, though taoJSON can also do direct-from/to-standard-and-custom-C++-types which can make up for (part of) the difference. Have you looked at https://github.com/miloyip/nativejson-benchmark yet?

[patlecat]

Thanks, haven't seen this yet. RapidJson is apparently also 100% standard compliant and still faster by factors. But that was in 2016. Wonder how they compare today.

[ColinH]

And taoJSON was the first (still only?) other library to achieve 100% conformance in the nativejson benchmark!

[d-frey]

@patlecat I don't think there were significant changes, although taoJSON might get a little bit faster. But there are a few points why libraries like RapidJSON are currently much faster:

• They have hand-optimized parsers that use SIMD-instructions to skip whitespace, etc. You could try and have such a parser generate the necessary events for taoJSON, hence leveraging the parser speed and still use the rest of our library. But maintaining such a parser in a portable way is a lot of work.
• The in-memory structure of RapidJSON is basically just one big chunk of memory and they are writing a constant stream of data in it. In a way, RapidJSON's memory representation of the data is like a binary serialization format. Manipulations of the structure become harder when you try and move values around or insert/delete somewhere in the middle.
• That said, you could also try and connect such a "fast" in-memory representation with our library. After all, RapidJSON does use an events-interface internally AFAICT. Maybe we should also try and benchmark taoJSON when using a binary format (we have CBOR, UBJSON, ...) instead of the "usual" value class. @ColinH What do you think? Is it worth a try?

[patlecat]

Haven't tried taoJSON but is it keeping the data tree accessible like a sort of DOM? Then of course that would make modifications and additions a lot faster and parsing slower. It's been the same decades ago with XML parser, the stream parser were always faster.

[d-frey]

To understand the design of taoJSON (and other libraries, including RapidJSON), you need to separate the parser from the value object. The parser will generate events (SAX-style, or "stream parser"), and from these events you generate a DOM-style object. But that is only one option, you can also directly generate a (pretty-)printed string, you can generate CBOR, UBJSON, or some foreign library's value object. Also the parsers for incoming CBOR, UBJSON, etc. generate the same events, so you can covert CBOR to pretty-printed JSON without and intermediate DOM-style object. In the nativejson-benchmark there are also SAX-style tests where you can see that only some libraries are participating, including taoJSON.