プロが教えるわが家の防犯対策術!

だいぶ製作中のアプリケーションも、自作ファイル形式も
かなり大きい(よほどの場合により数百MBとか)ファイルを扱う可能性が生じてきたので
必ず全部メモリに読み込むのは推奨できない、という状況になりました。


そこで
既存のファイルからは読み取り専用で
メモリマップドファイルとして開き、普通のメモリ上に読み込まずともポインタ操作できるようにし

操作したい場合は読み書きできるメモリマップドファイルを、自分のアプリの指定フォルダに作業領域として作ったところから使用中だと判断出来るようにしておいて確保し
アドレスはオフセット等で管理し、ポインタを移し替えたりする、という手を使い

また、うまく処理を切り分けてやることにより
重要な個所についてはメモリ上に確保し、そこにデータにフィルタ演算するついでに移し替えたりするなど
さまざまな手によって

かなりの速度も実現出来ることが確認できました。

これはつまり、メモリではなくメモリマップドファイルを
可変長メモリプールとして使うという形になっています。


ただ、昨日思いつきで作って、とりあえず十分快適に動作は出来るけども、最適解かどうかは手探り状態、ともいえるので
よりよい方法が考えらるならぜひ知っておきたいです。

と…書いてる途中で
今は「使用中」「未使用」のフラグとそのサイズを持たせたリストを、一方向にnextポインタでつなぐのみ、となっていますが

空きリストのみ(も?)収集して…という方法の概念を思い出しました。
あまり複雑になるとバグが出る危険性はありますが、試す価値はありそうです。

ただ

・まず、メモリマップドファイル自体については、作った後はそのファイル自体は固定サイズ、ってことで良いでしょうか?

・可変長メモリプールなどのアルゴリズムについて、把握するのに何日もかかりそうなあまり巨大なコードになりすぎない範囲で、考察したりオープンソースで作ったりしているサイトなどがあれば教えていただきたいです。

A 回答 (1件)

メモリマップドファイルは標準には含まれない (はず) なので, その実装などは使っているシステムに依存すると思います. 例えば,

Windows なのか FreeBSD なのか Linux なのかによって違うかもしれませんよ.

この回答への補足

(12/27)
久しぶりに見てみたら

メモリマップドファイルではなくメモリ上での可変長プールで、単独での解放手順がないバージョンはEfficient C++に載っていました。
やはり単独での解放手順があるのとないのとでは結構必要事項の量が変わってきますが

(その他の色々なサイトなども含め)少なくとも、現状かなりいい線いってることは確かなはずと感じたことと

システム依存という情報が得られたこと(この情報があるだけでかなり色々なことが考えられますので)を踏まえ
今回の質問は締め切りとさせていただきます。

ども、ありがとうございました。

補足日時:2011/12/27 14:24
    • good
    • 0
この回答へのお礼

ご回答ありがとうございます♪

それは重要な情報ですね。

考えてみれば、OSと密接に関係してそうですからね。
将来的な移植の可能性を考えると、あまり長すぎるコードを組むのも得策ではないかもしれません。


とりあえずは、WindowsのXP以降を対象と考えたいところです。


ちょっと確認してみたら、現在は宣言と定義で占めて550行程度でした。
アプリケーションの総合的なパフォーマンスを考えると
これはかなり重要な部分ではあるので

逆に、内容にもよりますが、1000行くらいまでなら移植するのもそれほどきつくはないかな、と思っています。

お礼日時:2011/12/23 23:09

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!