Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112692
MIME-Version: 1.0
References: <CAH5C8xVr9zVyyzKAVM=D56-oMVGf9Nsxqa4rq9k1xM+gsH2SPg@mail.gmail.com>
 <8c1f2d5a-6888-0787-06ad-095a06dd4e7a@php.net> <CAEKnhAHqKe-RjC=M69ZoZNrfexi08gLvXbQjQJz9DAuAHmAHqg@mail.gmail.com>
In-Reply-To: <CAEKnhAHqKe-RjC=M69ZoZNrfexi08gLvXbQjQJz9DAuAHmAHqg@mail.gmail.com>
Date: Thu, 31 Dec 2020 02:30:35 +0100
Message-ID: <CAH5C8xWHub_oqqjx5VrqP_mSAmGuOGpggU6iaN0gczti9smS3A@mail.gmail.com>
To: Jakub Zelenka <bukka@php.net>
Cc: Remi Collet <remi@php.net>, PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000caf31505b7b89293"
Subject: Re: [PHP-DEV] [RFC] Bundling ext/simdjson into core
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--000000000000caf31505b7b89293
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Remi and Jakub,

>
I agree it's too early as the library is young and won't be available in
>> many distros. The PECL path is better in this case IMO as it will allow
>> some time .
>
>
In my opinion, this is a case where making an
exception is worth considering.

Should the simdjson library be written in C,
I'd propose to add the new API + parser to
ext/json directly, since ext/simdjson is just a
very small wrapper around the parser, and
not a complex piece of code in itself (compared to other parts of php-src).

Also, I think the performance benefit of using
the simdjson parser is so major that it would
be a pity if people had to wait for years until
the functionality becomes generally available
as a core extension. As json_encode() and
json_decode() are very easy to use, my guess
is that a 3rd party JSON-related extension
would never get an adoption large enough,
because only those people would install it
who have really reached the limitations of ext/json.

By the way, it has just come to my mind that
our company is also affected by these
limitations. Sometimes we have to parse
very large JSON documents, and in some
cases these can end up being truncated.
Fortunately we only need a specific part of
the data, so someone wrote a partial "parser"
(this is euphemism) tailored for the schema
in question. Rather than having to use
custom hackery, it would be so much better
if PHP would offer partial parsing out of the
box, like what the proposed
JsonParser::getKeyValue() does.

That said, the cost-benefit ratio of having
simdjson in core seems advantageous for me.

Was thinking that it would be good to consider some kind of plugable
> decoder where another extension could register a parsing callback.
> Something similar to what we have for parser but instead for the whole
> decoding. That would allow to still use current parser in json_decode but
> if simdjson available / configured in ini, then it would used instead and
> would be just faster. Not sure if all options are supported though - for
> example don't see any note about UTF8 substitution
> (JSON_INVALID_UTF8_SUBSTITUTE).
>

This is a very interesting approach, and it reminds me about the hashing
registry RFC
in certain extent.

And you are right, as far as I saw, these flags
are not supported by ext/simdjson. But to be
honest, I haven't analyzed yet how difficult it
would be to have a reasonably full compatibility with ext/json.

Cheers:
M=C3=A1t=C3=A9

--000000000000caf31505b7b89293--