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

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2024-03-01 00:51:37

On Thu, Feb 29, 2024 at 5:40 PM Vinnie Falco via Boost
<boost_at_[hidden]> wrote:
>
> On Thu, Feb 29, 2024 at 3:14 PM Christian Mazakas via Boost
> <boost_at_[hidden]> 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