Nikita Popov
npopov.com · Personal blog · on HN since 2021
Nikita Popov, an LLVM and PHP contributor, writes about compiler internals, LLVM compile times and IR design.
What HN saysCommenters cite his posts on LLVM compile-time performance and Scalar Evolution, and note his many accepted improvements to PHP.
36HN people shared it
16linked it in comments
27stories submitted
373story points
3 months agolast shared
2021people per year2026
Most-shared posts
- 1Make LLVM fast again7 people · first shared 2021
- 2Regular expressions with backreferences are NP-complete (2012)5 people · 7 points · first shared 2022 · 1 comments on HN
- 3Design Issues in LLVM IR3 people · 175 points · first shared 2021 · 6 comments on HN
- 4This Year in LLVM (2024)3 people · 5 points · first shared 2025 · discussion on HN
- 5LLVM: The Bad Parts3 people · 5 points · first shared 2026 · discussion on HN
- 6LLVM: Scalar Evolution (SCEV)3 people · 2 points · first shared 2023 · discussion on HN
- 7AboutMe3 people · first shared 2022
- 8How PHP Opcache Works2 people · 151 points · first shared 2021 · 82 comments on HN
- 9This Year in LLVM2 people · 10 points · first shared 2024 · discussion on HN
- 10Are PHP Developers Functophobic?2 people · 4 points · first shared 2021 · discussion on HN
- 11This Year in LLVM (2022)2 people · 2 points · first shared 2022 · discussion on HN
- 12PHPs new hashtable implementation2 people · first shared 2021
- 13This Year in LLVM (2025)1 people · 3 points · first shared 2026 · discussion on HN
- 14The Opcache Optimizer1 people · 3 points · first shared 2022 · discussion on HN
- 15LLVM: The middle-end optimization pipeline1 people · 2 points · first shared 2023 · discussion on HN
What HN people wrote when they linked it
neolog · 2021-07-26
That's great to hear. I found some info about it which looks promising.
https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html
nebezb · 2025-12-24
https://www.npopov.com/2023/10/03/LLVM-Scalar-evolution.html
“basic and essential” are interesting ways to describe the field of compiler optimization research.
Are you suggesting that the discovery and implementation of SCEV in LLVM is basic and essential? Or that summing integers in a range is basic and essential?
kibwen · 2023-11-28
Note that Nikita has had a hand in many of the improvements that have made PHP much more pleasant since the fractal-of-bad-design days: https://www.npopov.com/aboutMe.html#accepted-php-proposals
Tainnor · 2023-05-17
HTML is not regular, so it can't be recognised by a "theoretical" regular expression, such as introduced in a theoretical CS class. Modern regex engines however, are more powerful and can recognise non-regular languages too.
Then there's a distinction to be made between recognising a language and parsing it.
This article goes into more detail: https://www.npopov.com/2012/06/15/The-true-power-of-regular-expression…
diimdeep · 2023-03-18
Is it slower again ? [1]
[1] https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html
w-m · 2023-03-18
https://www.npopov.com/2022/12/20/This-year-in-LLVM-2022.html#compile-…
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.
TazeTSchnitzel · 2022-09-13
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.ht…
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.
heurisko · 2022-08-05
Opcache is integrated into PHP since 5.5. It's been stable for around two decades.
https://www.npopov.com/2021/10/13/How-opcache-works.html
pooya72 · 2022-02-07
Also a lot of the positive changes were do to the efforts of Nikita Popov[1] who has now left. It's led to the creation of the PHP foundation.[2] I haven't kept up to date with the foundation's efforts.
[1]:https://www.npopov.com/aboutMe.html
[2]:https://blog.jetbrains.com/phpstorm/2021/11/the-php-foundation/
mhitza · 2022-01-11
> 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
sanxiyn · 2022-01-09
LLVM has been negligent about compile time for a long time, but they are improving recently. See https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html for an example.
fault1 · 2021-12-18
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.
masklinn · 2021-11-23
> that was around PHP 7.0
7.0 is when php switched to open addressing: https://www.npopov.com/2014/12/22/PHPs-new-hashtable-implementation.ht…
BadInformatics · 2021-07-26
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
ianlevesque · 2021-05-27
There was actually a really good push to both optimize LLVM and prevent regressions last year. See https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html
flohofwoe · 2021-04-27
> 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