On 23. Oct 2019, at 00:33, Vinnie Falco wrote:

On Tue, Oct 22, 2019 at 3:13 PM Daniel Frey via Boost 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.