ですから、これは以前に数千回出てきたに違いありませんが、Android と iOS でのガベージ コレクションが非常に遅い理由を詳しく説明しているこの記事を読んだところです。
重要なポイントの 1 つは、コレクターが作業するための十分な空き領域がある限り、ガベージ コレクションは問題ないということです。
私の質問は、GHC のメモリ管理実装もこの影響を受けやすいのでしょうか?
ですから、これは以前に数千回出てきたに違いありませんが、Android と iOS でのガベージ コレクションが非常に遅い理由を詳しく説明しているこの記事を読んだところです。
重要なポイントの 1 つは、コレクターが作業するための十分な空き領域がある限り、ガベージ コレクションは問題ないということです。
私の質問は、GHC のメモリ管理実装もこの影響を受けやすいのでしょうか?
完全な状況はより複雑ですが、そうなる可能性があります。GHC は主にコピーコレクターを使用します。GC は、ヒープがある程度 (現在は 2x ) 大きくなるとトリガーされます。コピー コレクターの戦略は、ライブ オブジェクトを新しいメモリにコピーすることであるため、この記事で示されているようにライブ データ サイズの 6 倍ではありませんが、RAM の空き容量を確保することが非常に重要です。GHC の IIRC は約 2.5 ~ 3x が最小値です。
GHC はまた、余分な RAM をほとんど必要としない圧縮コレクターも提供します。コレクション スキームの圧縮とコピーの選択は、メモリ使用量とRTS-c
および-M
flagsに応じて動的に行われます。