[RFC] Switch from json extension to jsonc [Discussion]

Le 29/08/2013 08:25, Stas Malyshev a écrit :

Hi!

Subject: Switch from json extension which have a problematic (non-free)
license to jsonc dropin free alternative.

RFC: https://wiki.php.net/rfc/free-json-parser

From what I see in the benchmarks, while encoding is on par with current
implementation, decoding is more than 2x slower. This may be a problem,
especially for something like REST API that may have to decode decent
amount of JSON data. Can it be fixed?

From my analysis (profiling), most of the time is spent in memory
allocation calls.

As we used a parser from a library, we do
1- parse in library space
2- object tree allocation of the result
3- copy result from library space to php space
4- PHP object tree allocation

I don't see any good solution to optimize this except copying the code
from the library into PHP, and thus remove stop 2+3.

Also, I see the sizes of the encode results is different from ext/json.
Why is that?

Also, "Partial implementation of big integers parsing" is a bit
worrying. If we want to have drop-in replacement, partial
implementations would lead to trouble. Can it be fixed?

As the parsing is done in the library, we receive a int64. So to late.
As previously copying the code will allow such change.

Of course I have tried to avoid this (copying the code) and prefer to
keep the library unchanged... but...

Remi.

Le 29/08/2013 08:25, Stas Malyshev a écrit :

Also, I see the sizes of the encode results is different from ext/json.
Why is that?

Stupid bench... data include some values from microtime()...
Fixed.

I have to say that I'm not wildly enthusiastic about making this change over
what appears to be a fairly minor comment in the license, and without even
going into the discussion as to why we want to promote Evil :)

The main concerns I have are:

• Downwards compatibility. We've found one potential issue, how can we
  guarantee that there aren't others when we deal with a completely different
  implementation? I think that users that bump into apps suddenly breaking in
  obscure edge cases will not be very understanding when we explain to them
  that we did that over a licensing quirk - that I'm willing to bet they'll
  say isn't applicable to them...
• Performance. Again, for the same reasons, I think it'll be difficult for
  us to defend this decision in this context as well. We switched to a 2x
  slower implementation over this? Really?

I think that a better alternative would be enabling ext/jsonc to take over
the ext/json symbol space so that people who care about the license issue,
and/or are interested in the extra features - will be able to take advantage
of it as a drop-in replacement. Debian can come with this switch turned on.

I think it'd be best to resolve this in PHP because otherwise it means
Debian (& Fedora?) users will have the bad surprise of a quirky
implementation when deploying to prod, and I can imagine the
impossible-to-reproduce issues that will follow.

That said, your last proposal of at least having a switch in php like
--enable-evil-json sounds better than the current state. If we do have
an equivalent implementation though we might as well throw away the
existing one instead of keeping two IMO, but that's a detail.

Cheers

--
Jordi Boggiano
@seldaek - http://nelm.io/jordi