Benchmarks of Composer 2.0 vs 1.10
Composer is the premier dependency/packet manager used by the PHP ecosystem. The first stable version was released on March 1st 2012, the second major version, 2.0, was released on October 24th 2020. Two-point-oh promises speed and memory usage improvements, a big deal in software that is run very often. Not only on developer workstations, but automated CI/CD pipelines as well. With the scale of PHP, a significant efficiency improvement has an impact on global energy use. 🐘💖 🌍
Let's find out how Ibexa DXP 3.2, a complex modern PHP application built on the Symfony 5 framework, benefits from an upgrade from Composer 1.10.17 to 2.0.7 in the real world. The benchmarks are done on a MacBook Pro 13" with macOS 10.15.7, an Intel i5 CPU at 2 GHz and 32 GB of RAM. A comparison with a laptop with an Apple M1 CPU would represent an interesting chapter in the history of computing, but today I am interested in the relative improvements offered by a software update.
Network speed could be a variable here, but in this case it should be relatively stable and give an indication if Composer 2.0 offers some improvements in parallel downloads, similar to what the Prestissimo plugin offers for 1.10. My installation of 1.10 did not have Prestissimo enabled, but it can yield significant improvements. Ibexa DXP uses Webpack Encore for building front end assets, but I didn't want this included in the numbers so I disabled this and a few other scripts to focus on Composer perf.
I want to know the differences between a
composer install an a
composer update to evaluate the benefits in repetitive installs (e.g. in continuous integration and delivery environments) as well as improvements in dependency resolving. Composer does cache packages, so the benchmark includes a round with purged and caches. The PHP version used is 7.4.12 from Brew. I might do a follow up with PHP 8.0 later.
The benchmarks were run with the laptop on a cool desk and with no other applications running. This should limit CPU throttling. I ran the benchmark rounds three times with both Composer 2.0 and 1.10 and used the best value for the report. I used a shell script whose resolution is 1 second, but I think this is enough because it's quite insignificant if something takes 13.37 seconds or 14.21 seconds at this scale.
Results and Conclusion
The benchmark round included the following with an Ibexa Experience installation:
- Install without a lock file and purged caches
- Require a new package (novactive/ezseobundle)
- Install with lock file, with purged caches
- Install with lock file, with filled caches
Installation time is much improved with Composer 2.0 in every case except when installing with a lock file with purged caches. This might be a network connectivity, or might be a characteristic of Composer 2.0 and I might revisit this later. But for the resolving process the full dependencies is around 50% faster, and a repeated install (often in CI/CD environments) is also over 25% faster. Definite improvements.
Memory usage may seem insignificant since this will be only a temporary occurrence and has nothing to do with how much memory your live application will use each time it is executed. But resolving the full dependency tree on a local installation takes a lot of RAM with Composer, leading to increasing the PHP memory limit to get it done.
In some cases it might even be impossible to resolve because of the lack of physical RAM on a server or workstation. Here is where Composer 2 really shines. Memory usage is cut down drastically for both a full resolve (711MB vs 2.5GB), and partial resolve (81MB vs 648MB) between Composer 2.0 and 1.10. At install time in a cached environment 2.0 actually consumes more RAM, but since this is insignificant at this scale (52MB vs 37MB) the performance benefits outweigh the added memory use.
Overall an upgrade from Composer 1.10 to 2.0 can yield some very substantial improvements both at development time as well as in continuous development in production with repeated installs. For example a large team that would do a hundred fully automated CI/CD pipeline deploys a day could save over 8 minutes of computing time a day. Over years and years this will add up to a significant reduction in consumption.
If you want to reproduce the tests on your local installation or have a closer look, I have created a Gist with some scripts and logs: Benchmarking Composer 2.0 and 1.1
Update: Due to a request I did Composer 1.10 and 2.0 on eZ Platform EE 2.5 (LTS) too.