レイアウトサイズとメモリ消費

以前「レイアウト面積が等しければメモリ消費も等しいはず」という仮説の元に書いた技術情報を公開しましたが、今回はその検証をおこないましたので、その結果を紹介します。先に結論を示し、後段に検証方法と結果をまとめます。

 

(1) レイアウト面積が等しい場合、メモリ消費は等しい。

(2) プログラム(レイアウター+ビュワー)分を除いたメモリ消費とレイアウト面積の間には比例関係が成立する。

(3) レイアウトファイルを開いた段階では、地形編集(高度+テクスチャ)の多寡はメモリ消費に影響を与えない。

(4) 編成数がメモリ消費に与える影響はレイアウト面積のそれに比較して無視できる程度に小さい。

(5) DirextX9版ビュワーはメモリ消費が極めて小さい。

 

 

 

 

今回の検証ではレイアウト内の部品数は考慮に入れていませんが、少なくとレイアウト面積ほど激しい影響は与えないように見えます。

以上が今回の検証結果から導いた結論です。以下、どのように上記結論に至ったかをまとめておきます。

メモリ消費の算出には、Windows標準のタスクマネージャを使用しています。タスクマネージャを起動したまま計測したい状態を作り「メモリ使用量」欄の値が安定した時点での数値を測定値として採用しました。

<タスクマネージャの「メモリ使用量」欄>

 

 

タスクマネージャの報告する値自身がどの程度信頼に値するか、という本質的な問題は捨て置く。

この「メモリ使用量」には、Windows自身や当方環境における常駐型アプリケーションのそれも含まれます。そこで、まずWindows起動直後の値を計測し(当方では92MB)、レイアウターとビュワーを起動した後の値からそれを引くことでVRMのメモリ使用量と見なすことにしました。なお、KB単位(上画面では下3桁)の値はWindowsの特性上変動が激しいので切り捨てています。

レイアウトサイズとして、4つのVRMレイアウトファイルを用意しました。それぞれレイアウトサイズが 4000 x 4000、8000 x 4000、 4000 x 8000、8000 x 8000(いずれも単位はmm)になっており、単純な楕円形のループと、編成が1つ配置されています。

テストケースは5種類用意しました。まず(1)レイアウトファイルを開くのみ、(2)レイアウト全体を高度50mmに設定、(3)地形自動生成を実行、(4)地面テクスチャをランダムに設定、(5)編成をコピーし8つにする、の5種類です。

計測毎にWindowsを再起動してタスクマネージャのみ起動し、いずれかのサイズのファイルをレイアウターで開いた後、テストケースで定めた操作手順を施してビュワーを起動しました。この時点で[ALT]+[TAB]でWindowsのデスクトップへ戻り、タスクマネージャの値を計測しています。

以下に結果を表形式で示します。

 

参考までに当方環境。

 

Athlon 1GHz / 384MB RAM

RivaTNTUltra2 16MB VRAM

Windows2000 + SP4 + DirectX9

VRM3 2,3,4号+VRM2車両導入

 

<検証結果一覧>

 

MB以下を四捨五入した結果、値に若干のバラつきがみられるが、これは誤差の範囲と判断した次第。

 

 

 

 

 

編成は「コピー」したのみなので、今回の検証は「編成の種類が増えた場合にどうなるか」には答えていない。

一見して明らかなのは、テストケース間の差異が皆無という意外な結果でした。「地形編集がメモリ消費に影響を与える」という説が巷間ささやかれているようですが、少なくともファイルから読み込んだ瞬間においては影響がないようです。これは逆にいうと、VRMシステムのレイアウト管理においては、レイアウト面積分の高度情報・地面テクスチャ情報を管理するための領域がベタに確保されている、ということなのだろうと想定されます。

次に、レイアウト面積間の差異を比較すると、レイアウト形状(X/Z方向長)に関わらず、面積とメモリ消費の間に正の相関が見てとれます。少なくとも当方環境においては、VRMシステムの起動に154MBを要し、ここにレイアウト面積に対して0.38MB/m2を加えたものが、全体としてのメモリ消費になっているように見えます。これが、厳密な意味で比例関係になると断言するには、もう少し細かい検証を必要としますが、ほぼ比例にあると考えて差し支えないでしょう。

 

もちろん、この話と「地形編集を繰り返すことでメモリリークが発生する」というのは、まったく次元を異にする問題でして。

まぁ、そのうち検証してみるつもり、としておく。

 

ついでに、DirextX9版ビュワーについても同様の検証をおこなってみました。以下にその結果を表形式で示します。

このへんになると、再起動の繰り返しにウンザリしていたことはさておく。

まず気づくのは、極端な消費メモリの減少です。単純に比較すると従来版(3.0.2.0)に比較して100MBに減少になっています。同ビュワー付属のドキュメントには変更点の1つとして「起動時に必要な部品だけロードする様に変更しました。起動時間が短縮されています。」とありますが、これもその影響と思われます。

試しに、手持ちの2〜4号のレール全種を適当にレイアウトにバラまいてみると、消費メモリは12MBほど増加しました。すべての部品をレイアウトに展開すると従来版と同じメモリ消費になるのかについては未検証ですが、おそらくは同程度もしくはそれ以上になることが予想されます。

もう1つ気になる点は、レイアウト面積あたりの消費メモリが増加している点で、おおよそ倍になっています。これを問題視するかは意見が分かれるところでしょう。手持ちの部品すべてをレイアウトに使わない限り、総消費量が従来版を下回ることは確実ですし、そもそもすべての部品を使い切るレイアウトというのも、考えにくい状況です。

 

 

 

確かに起動時間は劇的に短縮されました。未体験の方はお試しあれ。

 

 

 

VRMoviesでは、手持ちのビデオカードの性能限界からポリゴン落ちが発生するため、従来版(3.0.2.0)で動画を生成しています。

以上、特段何の役にも立たないレポートですが、枯れ木も山の賑わい的コンテンツとして公開しておきます。

VRMoviesは、ここに紹介した技術情報について、読者のお手元の環境での再現性をいかなる場合においても保証いたしかねます。ご承知おきください。

 


Webmaster: ghost@nodus.ne.jp