A way to stop GC wasting CPU time on long-lived objects (GC generations or something else)
まだ誰も着手していません。
- 主要言語
- C
- スター
- 40.4k
- フォーク
- 8.2k
- 平均マージ
- 2日 13時間
- マージ済み PR(30日)
- 96
説明
Description
PHP's GC is currently unsuited to long-running applications because of the lack of GC generations.
Any application which has long-lived objects with many descendents (such as PocketMine-MP's Server) will currently experience significant performance hits from GC runs due to the expense of repeatedly scanning complex dependencies of these objects.
I haven't dived deep into this problem, but I did verify that just the Server alone winding up in the GC root buffer in PocketMine-MP (which it should never do, being an object that stays alive for almost the entire process) costs 1.7 ms of GC time on a 12700k. An average GC run in PM during normal operation costs somewhere in the ballpark of 15ms, despite creating almost zero cycles.
This is a massive performance impact to PM on account of its update cycle taking place every 50 ms, so a 15ms GC pause is serious business.
Runtimes like .NET and Java have GC generations to avoid this problem, which avoid frequently scanning complex long-lived objects.
I understand that the benefit to PHP is relatively small, given that the primary use case is to serve short-lived web requests, but implementing generations in GC would positively affect performance of long-lived applications.
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
リンク先の PocketMine-MP src/Server.php の例から始めて、長期間存続するオブジェクトグラフと報告されている GC コストを理解します。次に、PHP の GC 実装と関連するテストを探し、ここで説明されている繰り返しスキャンを再現して、長期間存続するオブジェクトに対する処理量を削減しつつ循環参照の回収を維持する、テスト済みのアプローチを完了条件とします。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- c, php
- 領域
- performance
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 20/100