Req #75400 [Com]: Already As JSON

From: Date: Thu, 26 Oct 2017 02:34:19 +0000
Subject: Req #75400 [Com]: Already As JSON
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-212323@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=75400&edit=1 ID: 75400 Comment by: jwalton at aretehs dot com Reported by: jwalton at aretehs dot com Summary: Already As JSON Status: Analyzed Type: Feature/Change Request Package: JSON related Operating System: Any PHP Version: 7.0.24 Assigned To: pollita Block user comment: N Private report: N New Comment: I would, but I don't have permissions to put anything in that mail list. Previous Comments: ------------------------------------------------------------------------ [2017-10-25 14:37:57] pollita@php.net As you've seen, the pushback is pretty strong atm, would you mind presenting your case on internals directly? ------------------------------------------------------------------------ [2017-10-25 00:45:46] jwalton at aretehs dot com So, surprisingly, unlike other PHP code (that I wouldn't touch with a 10 foot pole) the ext/json was surprisingly clean. I was able to add this functionality in myself in 15 mins. Tested it on one of my website and wow, what an increase in performance. Added JsonRawSerialize but I changed the function name to jsonSerialized (past tense). Same performance script (but done on a different machine) <?php $jsondata = file_get_contents("test.json"); $jd = json_decode($jsondata); class Test implements JsonRawSerializable { public $str; function __construct(&$str) { $this->str = $str; } function jsonSerialized() { return $this->str; } } $jrs = new Test($jsondata); function timing($func, $iter) { $stime = microtime(true); for($counter=1;$counter<$iter;$counter++) { $func(); } $etime = microtime(true); return $etime - $stime; } function json_decenc() { global $jsondata; $data = json_encode((object)[ "result" => json_decode($jsondata) ]); } function json_enc() { global $jd; $data = json_encode((object)[ "result" => $jd ]); } function json_str() { global $jsondata; $data = '{"result":'.$jsondata.'}'; } function json_raw() { global $jrs; $data = json_encode([ "result" => $jrs ]); } print "json_decenc = ".timing('json_decenc', 10000)."\n"; print "json_enc = ".timing('json_enc', 10000)."\n"; print "json_str = ".timing('json_str', 10000)."\n"; print "json_raw = ".timing('json_raw', 10000)."\n"; gave me json_decenc = 35.672137975693 json_enc = 14.386140823364 json_str = 0.11590504646301 json_raw = 0.35667610168457 only ~twice as slow as string concat, 99 times faster than decode(encode()), and its even faster than just re-encoding the same object. Unfortunately, the pure php json decoder/encoder doesn't hold a candle to the C one. To bad its not built in. All I did was check the return value Z_TYPE() == IS_STRING and then pass that directly to the smart_str_appendl() (saw that it was used for smart_str_appendl(buf, "true", 4); -> smart_str_appendl(buf, Z_STRVAL(retval), Z_STRLEN(retval)); I have a patch if anyone is interested. ------------------------------------------------------------------------ [2017-10-24 23:26:46] jwalton at aretehs dot com Created a performance script. php t.php json_decenc = 53.06218791008 json_enc = 18.900541067123 json_str = 0.18521690368652 function json_decenc() { global $jsondata; $data = json_encode((object)[ "result" => json_decode($jsondata) ]); } function json_enc() { global $jd; $data = json_encode((object)[ "result" => $jd ]); } function json_str() { global $jsondata; $data = '{"result":'.$jsondata.'}'; } json document is 278,567 bytes(276k) long. json_decenc (does a decode and encode of that data into a new json document) json_enc (only does an encode of already decoded data) This shows that 64% of the time is spent decoding the data as encoding that data is relatively fast. json_str is basically string appending, this is the fastest method but doesn't maintain json integrity. As for the messages in internal, I understand where they are coming from but they are assuming that people will be building these string. And while they CAN, the main draw to this is that it could be coming from a database like PostgreSQL which already maintains the integrity of the json (JSON data type can't be inserted invalidly) ------------------------------------------------------------------------ [2017-10-24 08:45:26] kelunik@php.net Assigning to you, pollita, because you plan to work on it. ------------------------------------------------------------------------ [2017-10-23 23:57:37] pollita@php.net That's not unreasonable. I'll propose it to the list and see about getting it into 7.3. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=75400 -- Edit this bug report at https://bugs.php.net/bug.php?id=75400&edit=1

« previous php.bugs (#212323) next »