お世話になっております。
ご返信ありがとうございます。
gc.AllowIncrementalReachabilityがクラッシュを誘発し、また、Experimental度合いが強く実用にかなわないとのこと、当方で把握できておらず大変失礼しました。
余計なお手間をとらせてしまい、申し訳ございません。
> DisregardForGCを試して行こうと思うのですが
> こちらの対応する場合に対象のObjectに対してはCluster化は必ず必要でしょうか？
Cluster化は不要となります。
DisregardForGCは、エンジン／ゲームの起動シーケンスにおける特定のタイミング（FUObjectArray::CloseDisregardForGC() の呼び出し）までにロードされたオブジェクトを常駐オブジェクトとみなし、GCの追跡対象から外す仕組みです。Cluster化はこの CloseDisregardForGC() 呼び出し後でなければ作成できません。こうした機序から、 DisregardForGCの利用にあたりCluster化を検討していただく必要はない、と申し上げることができます。
詳しくは下記のドキュメントをご参照ください。
> GC対象のオブジェクト数を確認する方法はありますか？
> Objectを削る中でこのあたりも確認できたらと思ってます。
CVar gc.DumpAnalyticsToLog を 1 に設定しますと、GCの1サイクルごとに詳しいStatsがLogにダンプされます。このダンプ中の、
> LogGarbage: Pre GC: Objects: 269191, Roots : 142, Clusters : 12345, Clustered Objects : 154321
の表示を参考にしていただくのが、もっとも手軽かと思います（特に Objects: N の箇所）。
ただし、このObjects数表示には、Root Setされたオブジェクトも含まれます。Root Setされたオブジェクトは解放対象ではありませんが、Reachability解析の起点となるため、Reachability解析の負荷はこのObjects数におおむねスケールするという点で、参考になる値かと存じます。
もし実際にReachability解析でどれくらいの量のオブジェクトが走査されたかを把握なさりたい場合は、 gc.DumpAnalyticsToLog の値によらず出力される LogGarbage のログとして、
> LogGarbage: GC Reachability Analysis total time: 9.68 ms (9.68 ms on reference traversal)
> LogGarbage: 9.68 ms for GC - 269191 refs/ms while processing 2606926 references from 269191 objects with 12345 clusters
のような行があるはずですので、こちらの「 processing N references from M objects with K clusters」の M objects 部の数値を確認していただけます。
なお、これらのダンプは Shipping ビルドでは利用できないため、Development または Test ビルドでご確認ください。
以上、よろしくお願いいたします。
[Attachment Removed]