Reduce memory allocated by var_export, json_encode, serialize, and other

[arnaud-lb]

smart_str uses an over-allocated string to optimize for append operations. Functions that use smart_str tend to return the over-allocated string directly. This results in unnecessary memory usage, especially for small strings.

See #8896

The overhead can be up to 231 bytes for strings smaller than that, and 4095 for other strings.

Here I change a few functions so that they trim the string before returning it.

[iluuu1994]

LGTM! Can't think of a better name for finalize.

[bwoebi]

strpprintf functions also use smart strings. Especially when printing a small value as zend_string, it can be very noticeable. Can that one also be improved?

and 4095 for other strings.

Yes, but this is not solved by a realloc. Allocations larger than 4 KiB are always on a page size multiple.

[devnexen]

LGTM! Can't think of a better name for finalize.

Definitively not worth a long debate :-) that s a detail.

[cmb69]

strpprintf functions also use smart strings. Especially when printing a small value as zend_string, it can be very noticeable. Can that one also be improved?

I think so, but that can be done in a separate PR. :)

[devnexen]

strpprintf functions also use smart strings. Especially when printing a small value as zend_string, it can be very noticeable. Can that one also be improved?

I think so, but that can be done in a separate PR. :)

I agree on this but worth doing nonetheless.

[cmb69]

Thank you for the PR!

I'm slightly concerned that the additional reallocation might decrease performance. It is okay, if we actually can save memory, but if not (see @bwoebi's comment), it might be better to avoid it.

[bwoebi]

At least if zend_alloc is used, and page_aligned(old_size) == page_aligned(new_size), nothing happens (if > 4 KiB). It's debatable whether it's worth short-circuiting this, as with big strings the relative overhead is minimal.

[arnaud-lb]

Did some benchmarks to measure the impact on execution time: https://gist.github.com/arnaud-lb/ac223f3e7cf6e6d818adb77bbbd0a182

The first benchmark measures the execution time of var_export($string), with strings of various lengths.

• There is no impact on strings larger than 4096 bytes
• When the result of var_export is discarded, there is a negative impact on execution time (17% slower with size=6; 8% with size=12; ). The impact decreases as the size increases.
• When the result of var_export is accumulated, there is a positive impact on execute time (44% faster with size=6). The impact decreases as the size increases.
• Short-circuiting the allocator makes no difference

There is no visible difference on other benchmarks (sub-1% difference, results vary in this range from multiple runs)

[cmb69]

Please don't forget to add a note to UPGRADING.INTERNALS when merging. A PR for https://www.phpinternalsbook.com/php7/internal_types/strings/smart_str.html would also be nice.