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áté
