> $memoryAfter = memory_get_usage(true) / 1024 / 1024;

I see that you used `memory_get_usage` that shows memory usage at the time
of the function call.
As far as I understand, your function does not return any value,
so I suspect that it is obvious that the memory usage after the function
call is the same as before.
But what is the actual memory usage during the function call?
Can you run the same benchmark but with `memory_get_peak_usage` function to
see how your function uses memory?

# $memoryAfter =  memory_get_peak_usage(true) / 1024 / 1024;

Also, I'm concerned if it would be better to name the function
`is_json_valid`?

On Sat, Jul 30, 2022 at 10:37 AM juan carlos morales <
dev.juan.mora...@gmail.com> wrote:

> 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 = 1000000;
> $jsonString = '{ "test": { "foo": "bar" },';
>
> for ($i=0; $i < $limit; $i++) {
>   $jsonString .= " \"test$i\": { \"foo\": { \"test\" : { \"foo\" :  {
> \"test\" : { \"foo\" : \"bar\" }}}}},";
> }
>
> $jsonString .= ' "testXXXX": { "foo": "replaceme" } }';
> //{ "test" : { "foo" : "bar" }}}
>
> $memoryBefore = memory_get_usage(true) / 1024 / 1024;
> echo "Megas used before call: " . $memoryBefore . PHP_EOL;
>
> $start = 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 = 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áb, 30 jul 2022 a las 3:50, Jordan LeDoux (<jordan.led...@gmail.com>)
> escribió:
>
> >
> >
> > On Fri, Jul 29, 2022 at 7:27 AM juan carlos morales <
> > dev.juan.mora...@gmail.com> wrote:
> >
> >> # Why this function ?
> >>
> >> At the moment the only way to determine if a JSON-string is valid we
> have
> >> 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
> validation
> > 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
> >
>

Reply via email to