PHP RFC: Implicit Move Optimisation

• Version: 0.1
• Date: 2023-05-13
• Author: Niels Dossche (nielsdos), dossche.niels@gmail.com
• Status: Draft
• First Published at: http://wiki.php.net/rfc/implicit_move_optimisation

PHP currently contains two data types which are copy-on-write (CoW): string and arrays. When you pass a variable containing a CoW type as an argument to a function, you don't copy the data. Instead, you increment the reference count of the data by one. The lowest possible reference count for a variable passed to a function is therefore 2: one reference is the variable, and the other is the function argument. Let's look at a toy code example:

function my_function(array $my_array) {
    // Remember: $my_array has a reference count of 2:
    //   one reference in $array (main), and one in $my_array (my_function).
    $my_array[] = 3;
    return $my_array;
}
 
function main() {
    $array = [0, 1, 2];
    $array = my_function($array);
    var_dump($array);
}
 
main();

The code example shows an array being passed to “my_function”, which modifies the array and returns the modified result. However, due to the copy-on-write (CoW) mechanism, the variable “$my_array” is duplicated within “my_function” because the array's reference count is greater than 1 and it is modified. In this example, the duplication is unnecessary since the result always overwrites the original array. The purpose of this RFC is to propose an optimisation for avoiding such unnecessary duplications.

While this example may not highlight the significance of the copy cost, there are scenarios where it does matter, such as processing large data batches (e.g., ETL-like processes) or complex functions. The reason for creating a separate “main()” function will become clear later in the proposal.

All the features and examples of the proposal.

To paraphrase Zeev Suraski, explain hows the proposal brings substantial value to be considered for inclusion in one of the world's most popular programming languages.

Remember that the RFC contents should be easily reusable in the PHP Documentation.

If applicable, you may wish to use the language specification as a reference.

What breaks, and what is the justification for it?

Next PHP 8.x (which is PHP 8.3 at the time of writing).

None.

None.

It is necessary to develop RFC's with opcache in mind, since opcache is a core extension distributed with PHP.

Please explain how you have verified your RFC's compatibility with opcache.

None.

None.

Make sure there are no open issues when the vote starts!

List existing areas/features of PHP that will not be changed by the RFC.

This helps avoid any ambiguity, shows that you have thought deeply about the RFC's impact, and helps reduces mail list noise.

None.

One primary vote with a simple yes/no option.

Current implementation: https://github.com/php/php-src/pull/11166

After the project is implemented, this section should contain

1. the version(s) it was merged into
2. a link to the git commit(s)
3. a link to the PHP manual entry for the feature
4. a link to the language specification section (if any)

Links to external references, discussions or RFCs

Keep this updated with features that were discussed on the mail lists.