PHPStan をできる限り高速化してみる

Transcript

1. ©COLOPL, Inc. PHPerKaigi 2025 - #phperkaigi PHPStan をできる限り 高速化してみる 株式会社コロプラ

   技術基盤本部 工藤 剛 2025.03.23 - PHPerKaigi 2025 / Lightning Talk Session

2. ©COLOPL, Inc. PHPerKaigi 2025 - #phperkaigi TL;DR

3. ©COLOPL, Inc. PHPerKaigi 2025 - #phperkaigi PHPStan 2.x に移行しろ 新しくて強い

   CPU を使え JIT を有効化しろ

4. ©COLOPL, Inc. PHPerKaigi 2025 - #phperkaigi 閑話休題

5. ©COLOPL, Inc. PHPerKaigi 2025 - #phperkaigi 名前: 工藤 剛 (a.k.a.

   zeriyoshi / ぜり) 所属: 株式会社コロプラ 部署: 技術基盤本部 サーバー基盤グループ 2017 年新卒入社 会社では主に PHP や Linux 周りのミドルウェア領域を 担当、必要な PHP Extension の開発・保守や各種 ミドルウェアバージョンアップ、 CI / CD 環境整備 など 自己紹介

6. ©COLOPL, Inc. PHPerKaigi 2025 - #phperkaigi それはさておき

7. ©COLOPL, Inc. PHPerKaigi 2025 - #phperkaigi デカいプロジェクトの PHPStan での 解析が遅すぎる

8. ©COLOPL, Inc. PHPerKaigi 2025 - #phperkaigi とあるデカプロジェクトの例 • マシンスペック ◦

   Google Cloud Compute Engine, n1-highmem-16 ▪ CPU: 16 vCPU (Intel Skylake 系) ▪ RAM: 104 GiB • 使用メモリ: ピーク時 93GiB • 実行時間: 約 40 分 ローカルマシンで動かすとか 夢のまた夢

9. ©COLOPL, Inc. PHPerKaigi 2025 - #phperkaigi 高速化1 - キャッシュを活用する PHPStan

   のキャッシュ機能を活用するようにしてみる 👍Pros: • 40 分 -> 23 分くらいに高速化できた • キャッシュ状況によっては 5 分程度で終わるようになった 👎Cons: • branch 作成後初回や merge / rebase 時にはほぼ意味を成さない • キャッシュが肥大化しまくりディスク容量枯渇が頻発 • 稀にキャッシュが壊れ Job が一切動作しなくなる 時短効果よりも保守の辛さのほうが勝る...

10. ©COLOPL, Inc. PHPerKaigi 2025 - #phperkaigi tmpfs を用いて Disk I/O

    を高速化してみる 👍Pros: • なし 👎Cons: • ただでさえメモリ使用量が厳しかったので、並列実行数を減らすしかない ◦ Disk I/O の改善効果より並列数が減ることによる速度低下のほうが問題になった • tmpfs 上の git リポジトリの管理が大変 ◦ 全部載せたらおもすぎるので必要なものだけ copy したり... やる価値はない！ 高速化2 - Disk I/O を高速化

11. ©COLOPL, Inc. PHPerKaigi 2025 - #phperkaigi アーキテクチャの見直しによって大幅にメモリ使用量を削減することができた が、従来のルールとの互換性が崩れるため長らく試験的機能に分類されていた tadsan の記事がくわしい:

    https://qiita.com/tadsan/items/75df674c17636f096ea2 👍Pros: • 全ての問題が解決する ◦ メモリ使用量、速度共に大幅に改善、フルで行ってもだいたい 10 分くらいで完了する 👎Cons: • 社内での内製ルールが軒並みぶっ壊れた 高速化3 - Bleeding Edge を有効化

12. ©COLOPL, Inc. PHPerKaigi 2025 - #phperkaigi ところで

13. ©COLOPL, Inc. PHPerKaigi 2025 - #phperkaigi 🎉 祝！ PHPStan 2.x

    🎉

14. ©COLOPL, Inc. PHPerKaigi 2025 - #phperkaigi 新機能や改善など嬉しいことがいっぱいあるが、要するに 長らく Bleeding Edge

    だった機能がデフォルト有効 になった、つまり... • 今までの内製ルールは大幅に手を加えなければならなくなった ◦ 動くよう手を加えれば、すなわち Bleeding Edge でも動くようになる • 将来的なメンテナンスを考えると 2.x に対応しないという選択肢はない ◦ Bleeding Edge 対応が「やれたらいいな」から「やらねばならぬ」に変わった • ステークホルダーへの説明がしやすくなった ◦ 「試験機能 (Bleeding Edge) 有効にしたら速くなるんですよ〜」から「バージョンアップ対 応が必要で、対応すると速くなるんですよ〜」では相手の受ける印象がだいぶ変わってくる PHPStan 2.x

15. ©COLOPL, Inc. PHPerKaigi 2025 - #phperkaigi ミドルウェア更新タイミングで すべてを PHPStan 2.x

    に移行

16. ©COLOPL, Inc. PHPerKaigi 2025 - #phperkaigi 結果

17. ©COLOPL, Inc. PHPerKaigi 2025 - #phperkaigi とあるプロジェクト: PHPStan 1.x ->

    2.x PHPStan 1.9.1 PHPStan 2.0.4 実行時間 キャッシュなし 40 分 13 分 キャッシュあり 23 ~ 6 分 数秒 メモリ使用量 キャッシュなし 93 GB 10 GB キャッシュあり 50 GB (うろ覚え) 8 GB

18. ©COLOPL, Inc. PHPerKaigi 2025 - #phperkaigi これはもう PHPStan 2.x に

    移行するしかないでしょう

19. ©COLOPL, Inc. PHPerKaigi 2025 - #phperkaigi • なんでメモリ使用量が少なくなってこんなに速くなったのかのまとめが 公式ブログに書いてあります ◦

    https://phpstan.org/blog/phpstan-1-6-0-with-conditional-return-types ▪ tadsan によるありがたい翻訳 https://www.phper.ninja/entry/2022/04/28/015632 • Disk IO バウンドやメモリバウンドだった傾向が薄れ、明確に CPU バウンドになりました ◦ PHP 8.x の OPcache JIT の効果が向上しました ◦ 例えば Intel Skylake な Compute Engine や Intel Coffee Lake で Ubuntu 24.04 な 物理マシン上で実行するよりも Apple M3 Pro で OrbStack (ファイルマウント) な ローカルマシンで実行するほうが速い ▪ Compute Engine n1-highmem-16: 約 13 分 ▪ Compute Engine c2-highcpu-16: 約 10 分 (highmem いらなくなったので変えた) ▪ 物理マシン OS: Ubuntu 24.04LTS CPU: Core i7 8700, RAM 64GiB: 約 11 分 ▪ OrbStack OS: macOS Sonoma, M3 Pro 11C, RAM: 36GiB: 約 8 分 余談