Re: New JSON library from the maker of Beast!

From: Daniel Frey (d.frey_at_[hidden])
Date: 2019-10-22 23:06:07

> On 23. Oct 2019, at 00:33, Vinnie Falco <vinnie.falco_at_[hidden]> wrote:
> 
> On Tue, Oct 22, 2019 at 3:13 PM Daniel Frey via Boost
> <boost_at_[hidden]> wrote:
>> That sounds like you should stop using the STL altogether. What if std::string is suddenly 2x slower? So... no, I don't buy that argument.
>> 
>> I just switched our JSON library <https://github.com/taocpp/json> from
>> our own classic enum+union implementation (back from the C++11 days)
>> over to std::variant (as we are now C++17 anyways).
> 
> Any idea why taocpp compiled with optimizations is 5 to 10 times
> slower than the other libraries at parsing the same inputs?

Yeah... I'd actually *try* to blame MSVC here :) We haven't benchmarked our libraries on Window as we are not Windows users ourselves. The numbers on Linux/MacOS should look different. Have you tested there as well?

So Emil's argument has some truth to it, but still I'd rather like to see the STL to improve rather than rolling back. But I haven't even verified it, so take that with a grain of salt.

> It seems like there's this thing called PEGTL which has some large
> number of functions showing up as taking up time in the profile? What
> is PEGTL?

The PEGTL is the Parsing Expression Grammar Template Library <https://github.com/taocpp/PEGTL>, our general-purpose parser library. the JSON library actually started out as a benchmark for the PEGTL. Obviously, the parser spends most time in some methods from the PEGTL. And older version that are in the nativejson-benchmark were doing quite well for a general-purpose parser framework <https://github.com/miloyip/nativejson-benchmark#parsing-time>. Not as fast as RapidJSON, but that also largely depends on the design choices for the value type to hold the result.