PHP garbage collection mechanism-performance considerations

Recycling may have subtle performance effects on the root, but this is only possible when comparing PHP 5.2 with PHP 5.3. Although in PHP 5.2, the record may be slower than the root at all, and other modifications to PHP run-time in PHP 5.3 reduce this performance penalty.

There are two main areas that have an impact on performance. The first is the memory footprint savings, and the other is the increase in execution time (run-time delay) when the garbage collection mechanism performs memory cleanup. We will study these two areas.

Savings in memory footprint

First, the entire reason for implementing the garbage collection mechanism is to save memory consumption by cleaning up the variables referenced by the loop once the prerequisites are met. In PHP execution, garbage collection is performed once the root buffer is full or when the Gc_collect_cycles () function is called. In, the following script shows the memory footprint of PHP 5.2 and PHP 5.3 respectively, excluding the basic memory that PHP itself occupies when the script starts.

Example #1 Memory Usage Example

<?php    class Foo    {public        $var = ' 3.1415962654 ';    }    $baseMemory = Memory_get_usage ();    for ($i = 0; $i <= 100000; $i + +)    {        $a = new Foo;        $a->self = $a;        if ($i% = = 0)        {            echo sprintf ('%8d: ', $i), Memory_get_usage ()-$baseMemory, "\ n";        }    }? >

In this very theoretical example, we create an object in which an attribute is set to refer back to the object itself. In the next iteration of the loop (iteration), a typical memory leak occurs when the variables in the script are re-copied. In this example, two variable containers are leaked (object container and property container), but only one possible root can be found: The variable that is unset. After 10,000 repetitions (a total of 10,000 possible roots are generated), the garbage collection mechanism is performed when the root buffer is full, and the memory of those associated possible roots is freed. This is easy to see from the jagged memory footprint of PHP 5.3. After each execution of 10,000 repetitions, garbage collection is performed and the related reused reference variable is released. In this example, because the data structure of the leak is very simple, the garbage collection mechanism itself does not have to do much work. From this chart, you can see that PHP 5.3 has a maximum memory footprint of about 9 Mb, while the memory footprint of PHP 5.2 is increasing.

Increase in execution time (run-time slowdowns)

The second area where garbage collection affects performance is the time it takes to release the leaked memory. To see how much time it took, we changed the script a little bit, had more repetitions and deleted the memory footprint calculation in the loop, and the second script code was as follows:

Example #2 GC Performance influences

<?php    class Foo    {public        $var = ' 3.1415962654 ';    }    for ($i = 0; $i <= 1000000; $i + +)    {        $a = new Foo;        $a->self = $a;    }    Echo memory_get_peak_usage (), "\ n";? >

We will run this script two times, one time by configuring ZEND.ENABLE_GC to open the garbage collection mechanism, and the other time when it shuts down.

Example #3 Running The above script

Time Php-dzend.enable_gc=0-dmemory_limit=-1-n example2.php# andtime php-dzend.enable_gc=1-dmemory_limit=-1-n exampl e2.php

On my machine, the first command lasts for about 10.7 seconds, while the second command takes 11.4 seconds. A 7% increase in time. However, when the script was executed, the peak memory consumption dropped by 98%, from 931Mb to 10Mb. This benchmark is not very scientific, or does not represent real-world data, but it does show the benefits of a garbage collection mechanism in terms of memory footprint. The good news is that for this script, when there are more cyclic reference variables in execution, the memory savings are increased by a percentage of 7% per time.

PHP Internal GC statistical information

Inside PHP, you can show more information about how the garbage collection mechanism works. But to display this information, you need to recompile PHP to make benchmark and data-collecting code available. You need to set the environment variable cflags to-dgc_bench=1 before you run it as you wish./configure. The following command string is the thing to do:

Example #4 recompiling PHP to enable GC benchmarking

Export Cflags=-dgc_bench=1./config.nicemake Cleanmake

When you re-execute the above example code with the newly compiled PHP binaries, you will see the following information after the PHP execution finishes:

Example #5 GC Statistics

GC Statistics-------------Runs:               110Collected:          2072204Root buffer length:0root buffer Peak:   10000      Possible            Remove from  Marked        Root    Buffered     buffer     Grey      --------  --------  -----------  ------zval   7175487   1491291    1241690   3611871ZOBJ  28506264   1527980     677581   1025731

The main information is counted in the first block. You can see that the garbage collection mechanism runs 110 times, and in all 110 runs, a total of more than 2 million of the memory allocations are freed. As long as the garbage collection mechanism runs at least once, the root buffer peak (root buffers peak) is always 10000.

Conclusion

In general, the garbage collection mechanism in PHP has a time-consuming increase only when the recycle algorithm is actually running. However, there should be no performance impact at all in the usual (smaller) script.

However, in the event of a recurring recycle mechanism running in a normal script, the memory savings will allow more of these scripts to run on your server at the same time. Because the total memory used does not reach the upper limit.

This benefit is particularly noticeable in long-running scripts, such as long-time test suites or daemon scripts. At the same time, for»PHP-GTK applications that typically run longer than web scripts, the new garbage collection mechanism should dramatically change the perception that memory leaks have always been difficult to solve.

