json: Improve performance of php_json_encode_array() for non-hooked fields

[TimWolla]

tmp can only ever be non-undef if there's a hooked object property, which is already an UNEXPECTED() case. Keep track of whether this case is hit or not to avoid needlessly calling zval_ptr_dtor().

For:

<?php

$len = 0;
for ($i = 0; $i < 3_000_000; $i++) {
	$len += strlen(json_encode(array_fill(0, 20, [])));
}
var_dump($len);

This is ~1.02 faster for a gcc 13.3 release build on a Intel(R) Core(TM) i7-1365U.

Benchmark 1: /tmp/bench/before /tmp/bench/test6.php
  Time (mean ± σ):     762.7 ms ±   3.2 ms    [User: 758.5 ms, System: 2.8 ms]
  Range (min … max):   759.2 ms … 769.3 ms    10 runs

Benchmark 2: /tmp/bench/after /tmp/bench/test6.php
  Time (mean ± σ):     748.3 ms ±   9.0 ms    [User: 744.3 ms, System: 3.1 ms]
  Range (min … max):   740.8 ms … 766.2 ms    10 runs

Summary
  /tmp/bench/after /tmp/bench/test6.php ran
    1.02 ± 0.01 times faster than /tmp/bench/before /tmp/bench/test6.php

[nielsdos]

On an older system (i7-4790):

  ./sapi/cli/php x.php ran
    1.09 ± 0.01 times faster than ./sapi/cli/php_old x.php

Nice find.
I think you could also remove the ZVAL_UNDEF(&tmp); line if you also guard the other zval_ptr_dtor occurrences, but that's of course entering more risky territory

[TimWolla]

I think you could also remove the ZVAL_UNDEF(&tmp); line if you also guard the other zval_ptr_dtor occurrences, but that's of course entering more risky territory

Yeah, too dangerous for me. I don't want to rely on zend_read_property_ex() definitely writing into the zval in 100% of the cases.