On Sun, Jul 31, 2022 at 4:41 PM Larry Garfield <la...@garfieldtech.com> wrote:
> So the core argument, it seems, is "there's lots of user-space > implementations already, hence demand, and it would be > better/faster/stronger/we-have-the-technology to do it in C." > There's innumerable features implemented in userland which would be faster/stronger/better done in C. I'm not convinced this alone is a sufficient basis to introduce a new core function. There are also userland JSON streaming parsers which are memory efficient, I've used the one I linked to parse JSON files over 1GB no problem. And I'm not saying I'm against this proposal, I'm just covering devil's advocate here - but while I can accept the number of userland implementations for "validate string as JSON" out there clearly show some demand / use cases for doing this, are there equally numerous examples of issues raised on these product repositories demonstrating userland implementations have commonly been insufficient, encountered OOM errors or otherwise caused problems? This might be an RFC to fix a problem very, very few people have. > > Thus another, arguably more important benchmark would be a C > implementation compared to a userspace implementation of the same > algorithm. Presumably your C code is doing some kind of stream-based > validation with braces/quotes matching rather than a naive "try and parse > and see if it breaks." We would need to see benchmarks of the same > stream-based validation in C vs PHP, as that's the real distinction. That > a stream validator would be more memory efficient than a full parser is not > at all surprising, but that's also not a fair comparison. > > As for the benchmarks themselves, do not use memory_get_usage(); as noted, > it shows the memory usage at that time, not ever. What you want is > memory_get_peak_usage(), which gets the highest the memory usage has gotten > in that script run. Or, even better, use PHPBench with separate sample > methods to compare various different implementations. It will handle all > the "run many times and average the results and throw out outliers" and > such for you. It's quite a flexible tool once you get the hang of it. > > I'll also note that it would be to your benefit to share the working C > code as a patch/PR already. If accepted it would be released open source > anyway, so letting people see the proposed code now can only help your > case; unless the code is awful, in which case showing it later would only > waste your time and everyone else's discussing it in the abstract before > the implementation could be reviewed. > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
