差分
このページの2つのバージョン間の差分を表示します。
| 次のリビジョン | 前のリビジョン | ||
|
ぷらしーぼ [2022/03/03 13:56] fumble 作成 |
ぷらしーぼ [2023/10/15 12:24] (現在) fumble |
||
|---|---|---|---|
| 行 2: | 行 2: | ||
| ====概要==== | ====概要==== | ||
| - | ダンス中に、不要メモリの解放処理を停止させることで、メモリ解放処理由来のかくつきを押さえるプラグイン。 | + | ダンス中に不要メモリの解放処理((GarbageCollector、GC))を停止させることで、メモリ解放処理由来のかくつきを押さえるプラグイン。 |
| ====ダウンロード==== | ====ダウンロード==== | ||
| - | https:// | + | https:// |
| ====詳細==== | ====詳細==== | ||
| - | ダンス中に、不要となったメモリを自動的に解放するGarbageCollectorを停止させることで、時々発生していたメモリ解放処理のためにかくつきを軽減します。\\ | + | ダンス中に不要となったメモリを自動的に解放するGarbageCollector(GC)を停止させることで、定期的に発生していたGC由来のかくつきを軽減します。\\ |
| また、他のプラグインから連動できるようにインターフェースを持っています。\\ | また、他のプラグインから連動できるようにインターフェースを持っています。\\ | ||
| + | \\ | ||
| + | 設定でワーキングセット((オダメが使用しているメモリ))の上限とGC対象メモリの上限の設定が出来ます。\\ | ||
| + | ワーキングセットの上限を超えた場合、GC停止処理は無効(GCが再開される)となりシーンが切り替わるまでGC停止は行えなくなります。\\ | ||
| + | GC対象メモリの上限を越えた場合、即時GCが行われGC停止状態は維持されます。\\ | ||
| + | ※何れのチェックもGC停止中のフレーム処理中に毎秒行われます。\\ | ||
| + | (そのため上限を超える時間がある程度発生します、余裕を見て設定してください。)\\ | ||
| + | 設定はファイルを直接書き換えるか、プラグイン起動中ならば同梱の設定「ぷ」ろぐらむで行えます。\\ | ||
| + | メモリに余裕がないPCは搭載メモリに合わせてワーキングセットの上限を設定することを推奨します。\\ | ||
| + | メモリに余裕があるPCの場合は、ワーキングセットの上限は無制限でも大丈夫です。\\ | ||
| + | GC対象メモリの上限は既定で3.75GBに設定しています、メモリが十分に余っている環境でも4GBを越えるあたりからオダメがメモリ不足で落ちる現象を見ており、こういった設定になっています。\\ | ||
| + | こちらを増やす場合は注意してください。なお、あまりに小さい値を設定すると毎秒GCが発生してカクカクになります。\\ | ||
| ====注意事項==== | ====注意事項==== | ||
| メモリ解放処理を止めるのでメモリの消費量が増大します。\\ | メモリ解放処理を止めるのでメモリの消費量が増大します。\\ | ||
| メモリに余裕がない環境での使用は避けてください。\\ | メモリに余裕がない環境での使用は避けてください。\\ | ||
| + | 小さすぎるGC対象メモリの上限を行った場合、毎秒GCが発生してカクカクになります。\\ | ||
| ====DanceCameraMotionのダンスについて==== | ====DanceCameraMotionのダンスについて==== | ||
| 行 20: | 行 32: | ||
| DanceCameraMotion 6.4.1以降であれば、自動的に連動します。\\ | DanceCameraMotion 6.4.1以降であれば、自動的に連動します。\\ | ||
| + | ====ちょっと技術的な話==== | ||
| + | ===ガベージコレクションについて=== | ||
| + | 使われなくなったメモリを自動的に解放する機能、プログラムで明示的に解放しなくてもよい代わりに、勝手に行われるため意図しないタイミングでかくつきが発生したりする。\\ | ||
| + | 新しいUnityはインクリメンタルガベージコレクション((簡単に言うとちょっとずつやることで全体的には遅くなるが、かくつきは減る動作))に対応していますが、オダメが使用しているものは対応していません。\\ | ||
| + | ガベージコレクションは「ながら」処理が行いにくい処理で、Unityでは全体が停止するような動作になります。\\ | ||
| + | ===「ぷ」ろぐらむが表示しているメモリについて=== | ||
| + | 「ぷ」ろぐらむが表示しているメモリは以下の二つ。 | ||
| + | * ワーキングセット(PSAPIのGetProcessMemoryInfoで取れるもの)、これはOS管理 | ||
| + | * GC対象メモリ(GC.GetTotalMemoryで取れるもの)、これはUnity管理 | ||
| + | ワーキングセットはいわゆるタスクマネージャーで見れるメモリ、簡単に言うと確保しているメモリの中で今使っているメモリ、つまり物理メモリ上に置かれるもの。\\ | ||
| + | 確保はされているが、ページファイル上に追い出されているものはここには含まれない。\\ | ||
| + | |||
| + | GC対象メモリはGCが管理しているメモリ(らしい)。\\ | ||
| + | |||
| + | GC対象メモリが増えると必然的にワーキングセットに置く必要性があるので最初はワーキングセットも増えて行きます。\\ | ||
| + | その状態でGCが発生するとGC対象メモリで不要だと判断されたものが解放されるので、GC対象メモリは減少します。\\ | ||
| + | が、ワーキングセットはこの時点では減りません。ワーキングセットはOS管理でGCは直接どうのこうのしません。\\ | ||
| + | 再度、GC対象メモリが増えた場合、GCが割り当てるメモリはワーキングセット内に(追い出されていなければ)あるはずなので、(既にワーキングセット内にある分は)ワーキングセットは増えずにGC対象メモリが増えていきます。\\ | ||
| + | |||
| + | PCでメモリ不足になった時に重くなるのは、ワーキングセットから追い出したメモリへのアクセスが発生し((ページフォルト))、戻す((ページイン))ために使われてなさそうなところを追い出し((ページアウト))して、戻す((ページイン))という動作をOSがするためです。\\ | ||
| + | ※追いだしたものがまたすぐ戻さなくてはいけなくなるような、どう考えても悪循環な動作ですよね？\\ | ||
| + | |||
| + | COM3D2.MemEmptyプラグイン(とあるプラグインの制作者 作)が明示的にこのワーキングセットを可能な限りページファイルに吐き出してワーキングセットを縮小するプラグインです。\\ | ||
| + | 吐き出した場合、ワーキングセットは一時的に縮小して、使用されるときにまたワーキングセットに戻されます。(この処理はOSレベルで重い処理になります。)\\ | ||
| + | ぷらし～ぼではOSレベルのメモリ管理には手を出していません。(現状、手を出す気はありません。)\\ | ||
| + | ※ここに書いていることはすごく簡単に書いています、実際OSはもっと複雑な処理を行っていて安易に手を出す部分ではありません。\\ | ||
| + | |||
| + | ====さらに技術的な話==== | ||
| + | オダメが使用しているUnityはGarbageCollector.GCModeにも対応していないので、Unity(mono)の内部関数を直接呼び出しています。\\ | ||
| + | 外部リンケージ((外からアクセスするための情報))を持たない内部関数をどうやって呼ぶかは[[appendix: | ||
| + | 要は実装されている関数順で、近くにある外部リンケージを持つ関数からの序数アクセスしています、従ってオダメが使用しているUnityのバージョンが変わって並び順等が変化した場合、正体不明の関数を訳のわからない引数で呼び出すことになり確実に誤動作します。\\ | ||
| + | ※要はオダメのバージョンよりオダメが使用しているUnityのバージョンが変わったときに互換性問題が発生します。 | ||