2つのチャンクを読む、それぞれ1Gbとする。最初のチャンクを処理し、次のパスで2番目のチャンクから「...少し前にシフトして」追加します。同時に、最初のチャンクの冒頭をカットする（常に「...shifting forward a bit」なので、もう必要ない。 2番目のチャンクが終了したら、3番目のチャンクを読む - そして今度は3番目のチャンクから「...shifting forward a bit」を追加してください。こうすることで、RAMには常に2つのチャンクが存在し（最大2GB）、ハードディスクへのアクセスは桁違いに少なくなります。
申し訳ありませんダミー、x64で制限がありますか？ここで私が遭遇した最初の記事です（まあ、最初ではない、大丈夫）x64システム下のSQL SERVER 2008のRAM制限-ベースが食べるのと同じだけのRAMです。
試してみるのもいいかもしれませんね。
ps maybe useful32 bit Windows 8 / 8.1 の 4 GB メモリ制限を解除 する。
情報量が多い（テキストファイルで 20GB程度）。
それならいっそ、バイナリに変換してしまった方が楽なのでは？ そうすれば、適当なサイズが得られるかもしれません。
情報量が多いのがもどかしい...。 10GiG だったら、RAM-diskに移して（実際はメモリに移して）読み放題にします。
まずはバイナリに変換して、サイズが合っているかどうかを確認するのが先決ではないでしょうか。
64ビット版へのアップグレード - 最大16TBのRAMが利用可能になります。
ファイルを バイナリ形式で保存 し、高速に読み取ることができます。
RAMサイズに応じたチャンクでファイルを処理します。
データの前処理を行い、重複する情報を排除するように心がける。
情報量が多い（テキストファイルで20GB程度）。
...
そして、これらのシークエンスに一度でも触れることが必要であれば、そうするつもりです。しかし、その都度少しずつ前にずらしながら、何度も通わなければならない。
...
塊で加工すると？
2つのチャンクを読む、それぞれ1Gbとする。最初のチャンクを処理し、次のパスで2番目のチャンクから「...少し前にシフトして」追加します。同時に、最初のチャンクの冒頭をカットする（常に「...shifting forward a bit」なので、もう必要ない。 2番目のチャンクが終了したら、3番目のチャンクを読む - そして今度は3番目のチャンクから「...shifting forward a bit」を追加してください。こうすることで、RAMには常に2つのチャンクが存在し（最大2GB）、ハードディスクへのアクセスは桁違いに少なくなります。
64ビット版へのアップグレード - 最大16TBのRAMが利用可能になります。
ファイルを バイナリ形式で保存 し、高速に読み取ることができます。
RAMサイズに応じたチャンクでファイルを処理する。
データの前処理を行い、重複する情報を排除するように心がける。
これはどの軸・バージョンに対応するものですか？ XPpro x64でも物理128まで、仮想16TBまで対応しています。
これはどの軸・バージョンに対応するものですか？ XPpro x64でも物理128まで、仮想16TBまで対応しています。
情報量が多い（テキストファイルで20GB程度）。
情報は同じような配列で構成されており、その数は約100万個。
すべての配列を繰り返し見て、計算する必要があるのです。
まず思いつくのは、ファイルの内容をすべて読み込んで、構造体の配列に詰め、メモリ上で作業することです。
しかし、うまくいかず、次のリサイズでMTは「Memory handler: cannot allocate 5610000 bytes of memory」と悪態をついた。
Dispatcherによると、terminal.exeは3.5GB RAMを使用しています（16物理のうち）。これは、プロセスが4GBしか取得できないからだと推測されます。
EAが「メモリが足りない（ 使用量4007Mb、使用可能量88Mb、合計4095Mb）！！」と言い出した。
しかも、これは必要額の15.3％に過ぎない（将来的にはもっと増やしたい）。
もう想像力がないんです。
では、この配列を、その時々に必要な情報だけを集めた多品種少量生産になるように組み替えればいいのだろうか？
データを縮小する（すでにできる限りchar型でfloatに変換している）？でも、それで得られるのはせいぜいあと10〜20％で、量を一桁減らさないといけない......。
何かアドバイスはありますか、友人たち？錆びないようにする）。
そして、データベースを使用する方向で、見ていないのですか？データベースを設定し、そこにテキストファイルからデータをダウンロードします。将来の計算のために、あらかじめデータの任意の集計を行うことができます。
Expert AdvisorからのSQLクエリ。
また、DBMSを別のサーバーに置くことで、トレーディングステーションのパフォーマンスを上げることも可能です。
皆さん、ご参加ありがとうございました。
今、週末でオフラインですが、朝には必ず皆さんに返信して、アドバイスを生かせるようにしたいと思います。
データベースの利用を検討されたことはありますか？データベースを構築し、テキストファイルからデータを読み込む。あらかじめ何らかのデータ集計を行い、さらに計算を行うことも可能です。
そして、Expert AdvisorからのSQLクエリ...。
DBMSは別のサーバーにインストールすることでパフォーマンスを向上させることができます。
考えてみた。意見に興味がある。
もう一つの考えは、すべてをデータベース(MySQL?)に移して作業することです。データベースは、このような大量かつ絶え間ない焼き直しに対応できるように設計されているということです。
専門家の方はいらっしゃいますか？誰が意見を言うのか？
ファイルを読み込む場合と比較して、何が高速化され、メモリ上で作業する場合と比較して、何が低速化されるのでしょうか？