Re: JSON and no-alloc

From: Marc Oscar Singer (elf_at_[hidden])
Date: 2023-08-14 19:25:36

On 8/14/23 12:05, Vinnie Falco via Boost-users wrote:
> On Mon, Aug 14, 2023 at 11:46 AM Marc Oscar Singer via Boost-users 
> <boost-users_at_[hidden]> wrote:
>
>     I'm targeting the boost JSON library for an embedded target. 
>     There appears to be one place where there could be either a
>     beneficial new feature, or the feature exists and I'm not seeing it.
>
>     The section about Avoiding Dynamic Allocation is close to what
>     we'd like to see, except that we don't want to depend on a stack
>     buffer for value data.  All of the text of the JSON message is
>     present in the string view. It would be desirable to reference the
>     values from there.
>
> When it comes to building a JSON library, there are many tradeoffs 
> that must be made. Tailoring the library for one use-case necessarily 
> inhibits other use cases or makes them less efficient. The design of 
> Boost.JSON is based on offering an efficient and flexible "value 
> type." That is, objects of type boost::json::value, which implement a 
> form of variant across the seven JSON native types: null, bool, 
> integer, floating point, string, array, and object.
>
> What you are describing is a completely different JSON library. For 
> example your model would be read-only, while instances of 
> boost::json::value are also writeable. Implementing the feature you 
> describe using Boost.JSON's existing types would be, to put it simply, 
> a huge hack and incur enormous technical debt. It would be much 
> cleaner to simply offer that as its own library. Or perhaps in another 
> namespace under Boost.JSON, which reuses very little of the existing 
> Boost.JSON code.
>
> However, this effort is unnecessary because there is already a great 
> library that does what you describe, and that is simdjson. Check it out:
>
> <https://github.com/simdjson/simdjson>
>
> Would this suit your needs?

Unlikely.  Remember, this is for an embedded target.  We are fortunate 
enough to have a 32 bit core.  simdjson requires a 64 bit CPU.

And, yes, of course ... tradeoffs.  I was hopeful when I read that 
"Boost.JSON works great on embedded devices."Â  For the kinds of embedded 
work we do, this is probably not the case.  We don't tend to parse and 
reedit JSON.  We tend to use JSON as a message serialization mechanism.

This discussion is academic for the time being.  The current release 
doesn't compile with ARM gcc and it doesn't appear to accept 
-fno-exceptions, even on MacOS, though I'm sure these details will be 
worked out.

Cheers

-- 
/Marc Oscar Singer/
*Woollysoft*
+1.206.328.1718