Hi
On 8/27/22 02:52, Dennis Snell wrote:
When asking if we want this in Core or if it's too hard to do reasonably-well
in user-land, here is an example
where we have working code that fulfills the same need as this RFC. If the
handful of motivating cases were
updated to use this user-land implementation would we still feel the need to
add this to the language? (Noting
too that even though it's third-party code, it's a single file that can be
copy/pasted without importing any library
or needing to fill out the typical request forms for code inclusion).
Yes, I would. This is something that makes sense to be "batteries included":
When using the userland implementation:
1. As a user I would need to do research to find the user-land
implementation. Depending on how good my search skills are, I might not
find it.
2. Afterwards I would need to evaluate the user-land implementation to
make sure it actually is any good. There's tons of crappy code out there.
3. Now I need to include it in my application one way or another
(composer / copy and paste).
4. Once included I would need to keep it updated, in case it has a bug.
With composer this might be easy-ish. When using copy and paste, not so
much.
5. If the native implementation is updated, then the maintainer of the
user-land implementation would also need to update it "in lock-step",
because otherwise they might return different results.
When using the native implementation:
1. I open the PHP manual, see something called json_validate().
2. I use it.
Takes 5 minutes, done, no more work needed. I can trust the native
implementation to be correct and consistent. Any updates will come
automatically whenever I update PHP.
If this does land in Core then can we at least do better on the performance
than `json_decode()`? I believe that
Not really. The parser is the same, thus the parsing performance is the
same.
json_validate() just saves on the memory allocation overhead for arrays
and objects, which is measurable for the RAM usage, but might not be
measurable for the CPU usage. So any improvements to the parser applies
to both. Any improvements in allocation performance will reduce the time
difference (but improvements in allocation performance are a good thing!).
The results in your linked gist, look odd though. Is 'is_valid_json()'
referring to 'json_validate()'? Did you use the most recent version of
the PR? I expect 'json_validate()' to be not slower than json_decode(),
because it does strictly less. Also the peak memory usage of 79M is
identical for all tested variants, this should not be the case for
json_decode().
Best regards
Tim Düsterhus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
