Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118318
MIME-Version: 1.0
References: <CANMwmbPkDLX4zXDNKh+zchgMxyGUdzSXkKO6eDgE0FPDR1Ezdg@mail.gmail.com>
 <CAMrTa2FpTxD9k+B0WUtR=8qYxjVJjUgVwGHf76dH2FkwjPUdWw@mail.gmail.com>
In-Reply-To: <CAMrTa2FpTxD9k+B0WUtR=8qYxjVJjUgVwGHf76dH2FkwjPUdWw@mail.gmail.com>
Date: Sat, 30 Jul 2022 08:37:09 +0200
Message-ID: <CANMwmbO-JOq9f6KZrtMSKLCJo1af+MhLyXMwdmF1ad20iSJChQ@mail.gmail.com>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009e11ab05e4ffff99"
Subject: Re: [PHP-DEV] RFC Idea - is_json - looking for feedback
From: dev.juan.morales@gmail.com (juan carlos morales)

--0000000000009e11ab05e4ffff99
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Just want to clarify that when I mentioned the use of memory, I wrote down
the function "memory_get_usage()", which basically gives us the memory
handle by php that is related to the memory_limit INI setting.

Now I will provide a benchmark I have done really quick:

# Code used (I have the implementation of is_json() done already)

<?php
// make sure you set your memory limit to -1 before running this code
// Here we create a very very very big json string, really big
$limit =3D 1000000;
$jsonString =3D '{ "test": { "foo": "bar" },';

for ($i=3D0; $i < $limit; $i++) {
  $jsonString .=3D " \"test$i\": { \"foo\": { \"test\" : { \"foo\" :  {
\"test\" : { \"foo\" : \"bar\" }}}}},";
}

$jsonString .=3D ' "testXXXX": { "foo": "replaceme" } }';
//{ "test" : { "foo" : "bar" }}}

$memoryBefore =3D memory_get_usage(true) / 1024 / 1024;
echo "Megas used before call: " . $memoryBefore . PHP_EOL;

$start =3D microtime(true);

json_decode($jsonString, null, $limit, 0);
//<------------------ un/comment to show/hide results for json_decode()
//is_json($jsonString);
 //<------------------ un/comment to show/hide results for is_json()

$memoryAfter =3D memory_get_usage(true) / 1024 / 1024;
echo "Megas used after call: " . $memoryAfter . PHP_EOL;

echo "Difference: " . ($memoryAfter - $memoryBefore) . PHP_EOL;

echo "Time: " . (microtime(true) - $start) . " seconds" . PHP_EOL;
return;

# Results
## json_decode()
Megas used before call: 79.23828125
Megas used after call: 3269.23828125
Difference: 3190
Time: 12.091101884842 seconds

## is_json()
Megas used before call: 79.23828125
Megas used after call: 79.23828125
Difference: 0
Time: 5.4537169933319 seconds


And yes, I am open to share the implementation, but after I write the RFC.

Thanks for taking your time to give me a feedback.

El s=C3=A1b, 30 jul 2022 a las 3:50, Jordan LeDoux (<jordan.ledoux@gmail.co=
m>)
escribi=C3=B3:

>
>
> On Fri, Jul 29, 2022 at 7:27 AM juan carlos morales <
> dev.juan.morales@gmail.com> wrote:
>
>> # Why this function ?
>>
>> At the moment the only way to determine if a JSON-string is valid we hav=
e
>> to execute the json_decode() function.
>>
>> The drawback about this, is that json_decode() generates an in memory an
>> object/array (depending on parameters) while parsing the string; this
>> leads
>> to a memory usage that is not needed (because we use memory for creating
>> the object/array) and also can cause an error for reaching the
>> memory-limit
>> of the php process.
>>
>> Sometimes we just need to know is the string is a valid json or not, and
>> nothing else.
>>
>
> You say that you have a first-pass at the implementation done. I'd be
> curious to see it. My initial thought was that in order to validate the
> string, you likely need to allocate extra memory as part of the validatio=
n
> that depends on the string size. You'd definitely save the overhead of a
> ZVAL, but for such an object that overhead is likely negligible.
>
> So I guess my question would be: in the actual implementation that lands,
> how much memory would this actually save compared to json_decode()? This
> seems like it would make the RFC tricky, as the purported benefit of the
> RFC depends very tightly on the implementation that lands.
>
> Jordan
>

--0000000000009e11ab05e4ffff99--