The garbage collection mechanism of PHP features-Factors to be considered in performance may affect the performance slightly, but it is only available when comparing PHP 5.2 with PHP 5.3. Although in PHP 5.2, the root of the record may be slower than the root of the non-record, other modifications to PHP run-time in PHP 5.3 reduce this performance loss.
There are two main fields that affect the performance. The first is the space savings in memory usage, and the other is the increase in execution time (run-time delay) when the garbage collection mechanism cleans up memory ). We will study these two fields.
Memory space savings
First, the whole reason for implementing the garbage collection mechanism is to save memory usage by clearing the variables referenced by the loop once the prerequisites are met. In PHP execution, once the root buffer is full or the gc_collect_cycles () function is called, garbage collection is executed. In, it shows the memory usage of the following scripts in PHP 5.2 and PHP 5.3 respectively, excluding the basic memory occupied by PHP when the script is started.
Example #1 Example of memory usage
self = $a; if ( $i % 500 === 0 ) { echo sprintf( '%8d: ', $i ), memory_get_usage() - $baseMemory, "\n"; } }?>
Run-Time Slowdowns)
The second area that affects the performance of garbage collection is the time it takes to release leaked memory. To see how much time this takes, we slightly changed the above script, there are more times of repetition and the memory usage in the loop is deleted. the second script code is as follows:
Example #2 GC performance influences
self = $a; } echo memory_get_peak_usage(), "\n";?>
We will run this script twice, one by configuring zend. enable_gc to enable the garbage collection mechanism, and the other by disabling it.
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 example2.php
On my machine, the first command lasted for about 10.7 seconds, while the second command took 11.4 seconds. The time is increased by 7%. However, the peak memory usage for executing this script is reduced by 98%, from 931 Mb to 10 Mb. This benchmark is neither scientific nor representative of real application data, but it does show the benefits of the garbage collection mechanism in terms of memory usage. The good news is that for this script, when more cyclic variables are referenced during execution, the percentage of increase in each time is 7% if the memory is saved more.
GC statistics in PHP
In PHP, you can view more information about how the garbage collection mechanism runs. To display this information, recompile PHP to make the benchmark and data-collecting code available. You need to set the environment variable CFLAGS to-dgc_1_= 1 before running./configure as needed. The following command string is used to do this:
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 binary file, after PHP execution is complete, you will see the following information:
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 primary information is counted in the first section. You can see that the garbage collection mechanism has been running for 110 times, and more than 110 of memory allocation is released during these 2 million times. As long as the garbage collection mechanism runs at least once, the Root buffer peak (Root buffer peak) is always 10000.
Conclusion
Generally, the garbage collection mechanism in PHP only increases the time consumption when the loop collection algorithm does run. However, in normal (smaller) scripts, there should be no performance impact at all.
However, when there is a recycling mechanism in normal scripts, memory saving will allow more such scripts to run on your server at the same time. Because the total memory used has not reached the upper limit.
This advantage is particularly evident in long-running scripts, such as long 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 significantly change the view that memory leaks are hard to solve.