Re: [boost] Reminder: Review for Zach's parsing library starts on Feb 19th

On Thu, Feb 29, 2024 at 5:40 PM Vinnie Falco via Boost wrote:

On Thu, Feb 29, 2024 at 3:14 PM Christian Mazakas via Boost wrote:

...

I copy-pasted the JSON example from the Parser repo and then did an informal comparison to Boost.JSON.

As I alluded to before the review started, that is grossly unfair.

I definitely think it's unfair (not apples-to-apples), but 1000x? Something's not right. So, it's good it's come up even if it's not an apples/apples comparison.

Boost.Parser is not optimized for JSON, and your Boost.Parser benchmark is also not optimized. I know this because optimizing the benchmark would take weeks and that amount of time hasn't yet elapsed. JSON uses custom memory allocators. I did not look too closely at Parser, but I am not sure if it has the API needed to customize how allocations are performed (I see Parser's implementation calls some "push_back" function in hot code paths). Zach could weigh in on this.

For a fair comparison, you would need this:

1. Boost.Parser offers sufficient customization so that an allocator optimized for JSON can be used 2. An optimized container for storing JSON is used (such as boost::json::value) 3. The benchmark for measuring Boost.Parser's JSON parsing performance is optimized

...

For one, Boost.JSON should just export a proper CMake target like all the other compiled Boost libraries.

If that does not negatively impact certain workflows (well, mine) then the maintainer should do this.

I think the allocator might have something to do with it, but it might also just be that Boost.JSON is just a more robust/efficient implementation than the toy I made for that example. Boost.JSON doesn't even allocate a lot of the time, IIRC. The JSON example uses a hand-rolled, dog-simple, allocate-all-the-time implementation for the JSON value type itself. Old-fashioned type erasure, no SBO, no COW, no nothin. That's why I'll be looking at the other example for comparison. The other one is a callback parser, and never actually makes any values. Testing *that* is much closer to testing the parsing speed. Zach