Improvements to Garbage Collection (GC) in PHP 7.3, 5x boost performance in tests
PHP continues it's long run as the world's favourite server side language in terms of adoption. The ubiqutious language continues to evolve as the team pushes new improvements now GC improvements are coming to PHP 7.3.
Garbage Collection is a method of memory management in many programming language runtimes. As opposed to unmanaged languages like C, C++ and Objective C where users need to allocate memory, languages with a GC like Java, JavaScript and PHP manage this automatically behind the scenes.
In general manual management of memory allows higher performance as users can specifically define the allocation of memory in the stack and heap. However, the practise is time consuming and this is why garbage collecting languages are used by most high level computing tasks requiring high efficiency. These include web applications for which PHP is most suitable for.
Dmitry Stogov working at Zend on the core PHP runtime has now merged a significant pull request to the language. The PR 3165 is labelled modestly as "GC improvement", but the work has potentially big effects on PHP applications dealing with amounts of memory.
Garbage collection always comes with some performance penalty, so improvements will affect performance across the board - but mileage will vary depending on the task at hand.
PHP 7.3 further improves memory management, JIT in PHP 8.0
The previous major release, PHP 7.0, brought significant performance improvements to the runtime. These were largely improvements in memory management. Coupled with fast VPS hosting (try a free $25 credit trial to high performance SSD VPS) solution and PHP can really scale way beyond the 5.x series. This is further expected to improve as PHP 8.0 brings JIT to the language.
The trend of performance has continues with each PHP 7.x version getting faster. With the PHP 7.3 release date set to late 2018 users will have access to this GC improvement very soon in their applications. The drop in changes for most applications yield significant increases in initial benchmarks with real world applications:
// Very, very, very many objects GC | OLD | NEW disabled | 1.32s | 1.50s enabled | 12.75s | 2.32s // Very many objects GC | OLD | NEW disabled | 0.87s | 0.87s enabled | 1.48s | 0.94s // Less many objects GC | OLD | NEW disabled | 1.65s | 1.62s enabled | 1.75s | 1.62s
The results clearly indicate that there is plenty of room emprovement here. With a large number of objects PHP speeds up at a tremendous scale. This will be especially useful for Full Stack Frameworks like Laravel or Symfony. These are commonly used for Content Management or eCommerce applications where large objects are often handled.
This is how Dmitry describes his findings:
Tweet
- With GC enabled, this is still 1.5x slower than with GC disabled (previously it was nearly 10x slower). This is because the (linear) GC threshold backoff happens too slowly for this case. I think this is fine to start with.
- With GC (runtime) disabled, we have a slowdown from the old to the new implementation (1.32s to 1.50s). perf shows that 10% of the time is spent inside
gc_remove_compressed. So this workload happens to use enough objects that the compression scheme becomes a problem...- https://github.com/php/php-src/pull/3165#pullrequestreview-100399813