Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68667
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fedoraproject.org from 212.27.42.3 cause and error)
Message-ID: <521EED22.6000808@fedoraproject.org>
Date: Thu, 29 Aug 2013 08:41:38 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8
MIME-Version: 1.0
To: PHP Internals <internals@lists.php.net>
References: <521EE223.9060702@fedoraproject.org> <521EE964.4080506@sugarcrm.com>
In-Reply-To: <521EE964.4080506@sugarcrm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Switch from json extension to jsonc [Discussion]
From: remi@fedoraproject.org (Remi Collet)

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.