On Wed, Dec 30, 2020 at 6:52 AM Remi Collet <r...@php.net> wrote: > Le 29/12/2020 à 17:57, Máté Kocsis a écrit : > > Hi Internals, > > > > I think this will be my last proposal for quite some while :) > > But this time, I'd like to propose bundling the > > https://github.com/crazyxman/simdjson_php extension > > with some major modifications. > > > > The proposed OO API is included in the description of the > > PR that I've just created: https://github.com/php/php-src/pull/6551 > > > > The main motivation behind this RFC is two-fold: > > - the underlying simdjson library (https://github.com/simdjson/simdjson) > > which is used by ext/simdjson provides huge performance gains > > compared to ext/json (see some benchmark results in the PR) > > - we can support new use-cases, most notably the so called "on-demand" > > parsing: > https://github.com/simdjson/simdjson/blob/master/doc/ondemand.md > > (This is not implemented currently) > > > > Originally, I planned to include the new API in ext/json, but > unfortunately, > > simdjson is written is C++, so it would make C++ as a hard dependency, > > which was not the case so far. That's why I opted for creating > ext/simdjson. > > > > Please let me know if you have any feedback. > > the library seems young and very active, and so probably not available > in most distributions. > > I would prefer to use the common way > > - propose as pecl extension > - wait for maturity (extension AND library) > - propose for merge in php-src > > IMHO: too early for this one. > > I agree it's too early as the library is too young and won't be available in many distros. The PECL path is better in this case IMO as it will allow some time .
That said the simdjson lib looks pretty impressive. Definitely looks more advanced than the ext json parser that I wrote more than 6 years ago. In my defese, I had no grant for that. :) Anyway really cool to see what can be done and how much it's possible to speed it up. 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). Cheers Jakub