風葉音 2007-03-17 00:11

·ファイルマッピングミスヒット

日本版MapleStoryのバージョン1.24において、データファイル(Data.wz)が分割されました。これは先行する韓国版では、他のアップデート内容と同じく昨年の冬に実施されたものです。

先日、廃れ企画のスカハイさんがこのファイル分割に言及する記事を書かれ、その中で動作遅延の解消についての技術的な意見を求められていました。が、昨日までにどなたからもレスポンスがありませんでした。

今回のパッチで必要な動作を必要な時に呼び出し、動かす、無駄の少ない仕様になったのだろう。
(もっとも、単に分割するだけで軽くなったら苦労しないので、当然中身の改良があったはずである)

専門じゃないが興味があるので、そのあたりどなたか教えてくださると幸いです。

それでは――ということで、ソフトウェア開発者の末席を汚すものとして不肖、わたし風葉音が動作遅延とデータファイル分割の関連性について考察してみました。(^^ゞ

以降、少々ソフトウェア技術的な内容になります。また、ソフトウェアの実装を見ることはできないので、単なる推測に基づく考察に過ぎません。あらかじめご了承ください。

MapleStoryのデータファイルは、実行中に繰り返しアクセスされることになる、約800MBにもなる巨大なファイルです。当然のこと「ファイルマッピング(オブジェクト)」(またはメモリマップドファイル)を使ってアクセスしているものと考えられます。

この記事の考察は、このファイルマッピングを使用しているという仮定のもとに進めます。

蛇足

ちなみに。

旧型では一つで7M強あったData.wzを扱って動かしていた(自分はこれをでかいプログラムの塊と思っていたが、フォルダと考えると別にそうでもない)わけで、そりゃあ要求スペック以上の負荷をかけることになっていたのだと思う。

スカハイさんの記事中では「7M(B)のプログラム塊」となっていますが、これはもちろん「700M(B)のデータ塊」の誤りでしょう。2桁少ないです。(^^; 3年半前のベータ時代でももうちょっとData.wzは大きかったようです。

ファイルマッピングとは、ファイル(の一部)を通常のメモリと同様にアクセスすることができる機能です。より簡単に表現すれば、メモリ上にファイルの「のぞき窓」を設けるようなものです――表現が適切かどうか、ちょっと不安(^^ゞ

知識のある方、使用したことのある方であれば、ファイルを意識することなくファイルにアクセスできるファイルマッピングが、ソフトウェアの実装にとってもプロセス――システムではありません――のメモリにとっても効率的なものであるということはご存知のことでしょう。しかし、当然のことながら実際にアクセスするときには、システムがその機能を実現するために実際のメモリ上にファイルの内容を読み込んでいることに変わりはありません。また、ファイルマッピングに使用されるメモリ領域も無限ではありません。のぞき窓があってものぞかなければならないこと、取り付けるための場所が必要となることと同じです。

そんなファイルマッピングを使用して、800MB近くもある単一のファイルにアクセスしていたのです。例えば、画面内に別のキャラクターが表示されることになれば、そのキャラクターの多数の装備画像を裸の画像に着せるように順番に表示してゆくわけです。いかに装備の分類ごとにデータファイル内でまとめられていたとしても、メモリ上に存在していないものは新たにディスクから読み込まなければなりません。ディスクのアクセスはメモリのそれよりも高コスト(処理時間を含む各種システムリソースがより必要)であるため、場合によっては表示遅延、ひいては動作遅延が発生することになります。

多くのキャラクターがいたとき、多くのモンスターやNPCがいたとき、別のマップに入ったときにはなおのことです。ちなみにのぞき窓モデルでは、ディクスからの読み込みはのぞき窓から見える部分を移動させることに相当します。

このキャッシュにおけるキャッシュミスヒットにも似た、いわば「マッピングミスヒット」ともいえるこのディスクアクセスの繰り返しが、結果として表示処理を高負荷なものにし、動作遅延を引き起こしていたものと考えられます。従って、メモリが多い環境、ディスクアクセスが高速な環境でプレイされていた方は、動作遅延は致命的なほどにはなっていなかったことでしょう。

ミルフィーユのように多数のアップデートが積み重なり、アイテムが増えるにつれ、モンスターが増えるにつれ、マップが増えるにつれ、データ全体に対するマッピング領域の比率は小さくなります。結果として、マッピングミスヒットによるディスクアクセスも次第に増加していたものと思われます。のぞき窓でのぞく必要のある場所が増えたため、その移動回数も多くなったということです。

今回のデータ分割によって、キャラクターやその装備、モンスターやマップと、それぞれ別々のファイル、すなわちファイルマッピングされるようになりました。つまり、今まで全データで共用していたのぞき窓に替わって、それぞれのデータ専用ののぞき窓が用意されたことになります。

これによって、メモリ上あるいはのぞき窓から見えるところに必要とするデータが存在する確率が大幅に上昇します。そのためマッピングミスヒットが、ディスクアクセスが低減され、結果として表示・動作遅延も完全とはいわないまでも解消されたということではないでしょうか。

* * *
·トラックバック i
name sign site
·コメント i ここでは「w≠笑」です。
スカ廃特務員さん 2007-03-17 19:47
·
なるほど、勉強になります。

なお、ご指摘にあった「7M」は「700M」に修正させていただきました。
「プログラムの塊」という表現も適切ではなかったですね。
風葉音 2007-03-18 22:27
·
スカ廃特務員さん(スカハイさん)。

ご覧いただきありがとうございます。
ご覧のとおり少々長く、また図を使わないと説明しづらいものでしたので、コメントではなくトラックバックとさせていただきました。
参考になりましたら幸いです。

また――

> 「プログラムの塊」という表現も適切ではなかったですね。

こちらについては本記事では触れておりませんが、データファイルが実行可能なEXEやDLLファイルの形式(PE形式)ではないため、プログラムではないと(わたしが)考えたに過ぎません。
また、基本的には実行可能なバイナリデータは前述の形式である必要がありますが、もちろん技術的にはそれ以外でも実行させるようにすることは可能です。しかし、それほどの実装力があればそもそも処理遅延を引き起こす状態にまでならなかったのではということもその理由としてあります。

ということで、こちらについてもわたしの仮定ということでご理解ください。
検索
メイプルストーリー
ロリポップ!
Opera
NOw 時間ねぇー