Adopting simdjson for JSON::XS?

[Marc Lehmann]

On Sun, Mar 19, 2023 at 07:58:15PM +0100, Peter Juhasz <peter.juhasz at comnica.com> wrote:
> would you be interested in a patch that adds the simdjson library as an
> alternative decoder to JSON::XS?

Hi, and sorry for the late reply - my fault.

Currently, JSON::XS has one of the best parsers there is in terms of
correctness, and I don't think it makes sense to replace it by something
of unknown quality that isn't compatible, and is far less portable (C++),
with all the associated build problems that c++ brings.

I think it would make most sense to have another module using simdjson, e.g.
JSON::SIMD or something along that lines.

I think for JSON::XS, it would make the most sense to simply replace the
slower parts, e.g. the string parsing, by something more optimized, and of
cours,e it should be in C, unless a good solution to build modules in c++ is
known (hint: there isn'*t).

Since IMHO the longest hanging fruit by a long shot is a single part
- satrinmg parsing - that would reap most benefits without associated
dangers and issues.

> would you object to a fork? I'm reluctant to publish a forked version
> though, the world doesn't need yet another Perl JSON module.

No, I don't object to a fork, as long as the license is adhered - thats
what free software is about.

I think my compromise above might be close to the best of all worlds here,
though - although having both faster string handling in JSON::XS AND a
fully separate module might be even better, as it allows more choice.

> the input '11111111111111111111111e1111111111111111111' is parsed as 0
> by JSON::XS. The documentation does say that "[n]umbers containing a
> fractional or exponential part will always be represented as numeric
> (floating point) values, possibly at a loss of precision", but in this
> case all of the precision is lost.

I consider this a bug and will have a look, thanks for notifying me.

> Perhaps it would be better to decode
> floating point numbers that don't fit into a double as strings,

The problem is detetcing those cases reliably - there is also the option
of Math::BigFloat.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\