Nikita Popov, an LLVM and PHP contributor, writes about compiler internals, LLVM compile times and IR design.
Commenters cite his posts on LLVM compile-time performance and Scalar Evolution, and note his many accepted improvements to PHP.
> no PHP dev will be think about memory management at all
Not nowadays, for sure. In 2009-2010 it was still something to keep in mind, and careful array handling was common so the it wouldn't baloon hundreds of megabytes for not so large data structures. I wasn't working on big data (tm) at that time, but running database imports via ETL processes in PHP required a few optimization passes.
I really can appreciate nowadays the huge memory and performance improvements that PHP went through from the 5.x days to the recent 8.1 release.
Sidenote: Shout outs to Nikita Popov who came to the scene and revitalized the language for me back then, for his proposals and features implemented in a time when PHP felt stagnant language wise https://www.npopov.com/aboutMe.html#accepted-php-proposals
Personally, I think interactive usage has improved quite a bit. I don't "feel" it that badly in 1.7. It was bad enough earlier in the 1.0 series that I stopped using it for a while (I used it before <1.0 as well).
I think the problems were from:
1) llvm itself getting dramatically slower over time, before more focus upstream on compiler speed more recently: https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html
2) different types of invalidations
3) less than ideal precompilation of packages
I think all of it has been improved, and can certainly be improved further. That also includes improving the speed of its interpreter (vs the JIT), which exists but was never optimized for speed afaik.
https://www.npopov.com/2022/12/20/This-year-in-LLVM-2022.html#compile-time
From the article:
I think this is the first time in quite a few releases where we end up with an overall regression. However, the situation is not quite as bad as it looks.
In particular, the large regression on the right is due to enabling C++17 by default. The close to two times slowdown in 7zip O0 builds comes down to STL headers becoming 2-3 times as large in C++17.
While this is sad, and I had to edit out some choice words on the C++ standardization committee (I hear that this gets even worse in C++20), at least this does not affect non-clang compilers (e.g. Rust) and C code.
> but compiling code will still be faster
I don't know about that, LLVM is getting slower with each new release too [1]. Same for Xcode: startup is very noticeably slower than a few years ago on the same machine. Starting into a debugging session for the first time is much slower (it used to be instant, now it's multiple seconds). The new build system in Xcode is most definitely slower than the old one, at least for projects with more than a handful compile targets. Etc etc etc... new software is only optimized to a point where performance doesn't hurt too much on the developer's machine.
[1] https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html
You may be interested in the current initiative around compiler plugins [1]. One of the explicit design goals is offload to alternative backends like GPUs or Wasm, but you could see how that would extend to something like Cranelift as well.
That said, LLVM codegen performance is very much a tail wagging the dog thing, and I wish upstream put a significantly larger focus on it [2]
[1] https://hackmd.io/bVhb97Q4QTWeBQw8Rq4IFw?view
[2] https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html
PHP does at least have an optimised internal representation for arrays with sequential integer keys, where it can avoid having a hash table and just do linear indexing: https://www.npopov.com/2014/12/22/PHPs-new-hashtable-implementation.html#packed-hashtables
But a tradeoff in that design is it still has to keep track of keys and update them if you remove stuff from the start of the array. Adding and removing elements at the end is very fast, though.