RAMコンパイル用ドライブ-そのようなものはありますか？
答え（以下を参照）ここStack Overflowの質問の1つに、あらゆる場所のコーダーにとって非常に貴重なソフトウェアのアイデアが浮かびました。 。
私はRAMドライブソフトウェアを想像していますが、1つの重要な違いがあります-それは私のハードドライブ上の実際のフォルダをミラーリングします。より具体的には-私が現在取り組んでいるプロジェクトを含むフォルダ。このようにして、ビルドはほぼ瞬時に行われます（または、少なくとも数桁速くなります）。RAMドライブは、アイドル状態のリソースのみを使用して、バックグラウンドでハードディスクドライブとその内容を同期します。
グーグルですばやく検索しても何も見つかりませんでしたが、グーグルのやり方がわからないのかもしれません。おそらく誰かがそのようなソフトウェアを知っていますか？できれば無料ですが、リーズナブルな料金でもかまいません。
追加： 私が最初に捨てたいくつかの解決策が提案されました。それらは（順不同で）次のようになります。
- より高速なハードディスクドライブを購入します（ [〜＃〜] ssd [〜＃〜] 多分または10K RPM）。 ハードウェアソリューションは必要ありません。ソフトウェアは安価になる可能性があるだけでなく（フリーウェア、誰か？）、ハードウェアの変更が不可能ではないにしても歓迎されない環境、たとえばオフィスでも使用できます。
- OS/HDDにキャッシュを任せましょう-空きRAMの使い方をよく知っています。 OS/HDDには、すべてをキャッシュし、将来最も必要となるデータを予測しようとする汎用キャッシュアルゴリズムがあります。彼らは私にとって優先順位が私のプロジェクトフォルダであることを知りません。そして、私たち全員がよく知っているように、とにかく実際にはあまりキャッシュしません。 ;）
- たくさんのRAMドライブがあります;それらの1つを使用してください。 申し訳ありませんが、それは無謀でしょう。少し空きがあるときはいつでも、データをHDDに同期して戻す必要があります。停電の場合、最後の5分間の作業を失うことに耐えることができましたが、最後のチェックイン以降のすべてではありませんでした。
追加2： 思いついたアイデア-通常のRAMドライブとバックグラウンドフォルダーシンクロナイザーを使用します（しかし、私は意味します バックグラウンド）。そんなことはありますか？
追加3： 面白い。単純なRAMドライブを動作させてみました。再構築時間は約14秒から約7秒に短縮されます（悪くはありません）が、インクリメンタルビルドはまだ約5秒です。 HDD。理由はありますか？aspnet_compilerとaspnet_mergeを使用します。おそらく、他の場所にある他の一時ファイルで何かをしますか？
追加4： ああ、素敵な新しい答えのセット！ :) OK、私はあなたのすべての否定論者のためにもう少し情報を持っています。 :)
このアイデアの主な理由の1つは、上記のソフトウェア（14秒のビルド時間）ではなく、その時点でアクセスできなかった別のソフトウェアです。この他のアプリケーションのコードベースは100MBで、完全なビルドには約5分かかります。ああ、そうです、 Delphi 5 にあるので、コンパイラはそれほど高度ではありません。 :)ソースをRAMドライブに置くと、大きな違いが生じました。1分未満でした。測定していません。したがって、OSができると言うすべての人にとってキャッシュの方が良い-私は違うように頼むだろう。
関連する質問：
最初のリンクに関する注記：リンク先の質問は重複していたため、削除されました。それは尋ねました：
コードのコンパイル中に何をしますか？
そして、私がリンクした Dmitri Nesteruk による答えは：
私はほぼ瞬時にコンパイルします。プロジェクトが小さいこともあり、RAMディスクを使用していることもあります。
Linuxでは（使用しているOSについて言及したことがないため、これが関連する可能性があります）RAMそして他のブロックデバイス（つまり、HDD）のようにそれらをマウントします。
次に、起動時/シャットダウン時、および定期的に、そのドライブとの間でコピーするスクリプトを作成できます。
たとえば、~/codeと~/code-realを持つように設定できます。 RAMブロックは起動時に~/codeにマウントされ、次に~/code-real（標準のハードドライブにあります）からすべてがコピーされます。シャットダウン時にすべてがコピーされます。 ~/codeから~/code-realにコピー（ rsync 'dの方が速い）。また、おそらくそのスクリプトを定期的に実行したいので、で多くの作業を失うことはありませんでした。停電などのイベント。
私はもうこれをしません（9.5ベータが遅いときに Opera に使用しました、もう必要ありません）。
この特殊なケースよりも、OSがキャッシュのニーズを把握するのに優れた仕事をすることができると多くの人が示唆していることに驚いています。コンパイルではこれを行いませんでしたが、同様のプロセスでこれを行い、同期を自動化するスクリプトでRAMディスクを使用することになりました。
この場合、私は最新のソース管理システムを使用すると思います。コンパイルのたびに、ソースコードが（必要に応じて実験的なブランチに沿って）自動的にチェックインされるため、コンパイルのたびにデータが保存されます。
開発を開始するには、RAMディスクを起動し、現在のベースラインをプルします。編集が保存されている間、編集、コンパイル、編集、コンパイルなどを実行します。
満足したら最終チェックインを行います。通常のハードディスクドライブを使用する必要はありません。
しかし、物事を自動化するバックグラウンドシンクロナイザーがあります-問題は、プログラミング用に最適化されておらず、変更をキャッチするためにディレクトリとファイルのフルスキャンを時々実行する必要があるかもしれないということです。ソースコード管理システムはまさにこの目的のために設計されているため、ビルドセットアップに存在していても、オーバーヘッドが低くなる可能性があります。
停電の場合のバックグラウンド同期タスクは定義されていないことに注意してください。問題が発生した場合、何が保存され、何が保存されなかったかを把握する必要があります。定義された保存ポイント（各コンパイル時、または手動で強制）を使用すると、少なくともコンパイルできると思った状態にあるというかなり良い考えがあります。 [〜＃〜] vcs [〜＃〜] を使用すると、前のコードと簡単に比較して、すでに適用した変更を確認できます。
tmpfsでemergeを高速化（ Gentoo Linux wiki）を参照してください。
GentooでRAMドライブを使用してコンパイルを高速化することは、何十年も前に書かれたハウツーの主題でした。これは、行われたことの具体例を提供します。要点は、すべてのソースとビルドが中間であるということです。ファイルはコンパイルのためにRAMディスクにリダイレクトされ、最終バイナリはインストールのためにハードドライブにリダイレクトされます。
また、ソースをハードドライブに保持することを検討することをお勧めしますが、git Push最新のソースがRAMディスクにあるクローンリポジトリに変更されます。クローンをコンパイルします。お気に入りのスクリプトを使用して、作成されたバイナリをコピーします。
それがお役に立てば幸いです。
OSは、動作時にメモリにキャッシュします。 RAMディスクの方が速いように見えるかもしれませんが、これは「RAMDiskへのコピー」と「RAMDiskからのコピー」の時間を考慮していないためです。専用RAM固定サイズのRAMディスクにすると、キャッシュに使用できるメモリが減るだけです。OSは、RAMに何が必要かをよく認識しています。
私はあなたが探しているものを正確に持っていませんが、私は現在 Ramdisk と DRAM ramdisk の組み合わせを使用しています。これはWindowsであるため、コアメモリに3 GBの厳しい制限があります。つまり、RAMディスクに多くのメモリを使用することはできません。9010で4GB余分に使用すると、非常に不安定になります。 IDEすべての一時的なものをソリッドステートに保存しますRAMディスクと Maven リポジトリ。DRAMRAMディスクにはフラッシュカードへのバッテリーバックアップがあります。これは宣伝のように聞こえますが、実際には優れたセットアップです。
DRAMディスクには2つのSATA-300ポートがあり、ほとんどのテストで平均0.0ミリ秒のシークが出力されます;）クリスマスの靴下に何かありますか？
https://wiki.archlinux.org/index.php/Ramdisk を使用して、RAMディスクを作成します。
次に、これらのスクリプトを作成して、ディレクトリをRAMディスクとの間で移動しました。 RAMディスクに移動する前に、バックアップは tar ファイルで行われます。この方法の利点は、パスが同じままであるため、すべての構成ファイルを変更する必要がないことです。完了したら、uramdirを使用してディスクに戻します。
編集：バックグラウンドで一定の間隔で指定されたコマンドを実行するCコードを追加しました。 tarと--updateを送信して、変更があった場合にアーカイブを更新します。
この汎用ソリューションは、非常に単純なものに対する独自のソリューションを作成するよりも優れていると思います。接吻
パスをrdbackupdに変更してください
ramdir
#!/bin/bash
# May need some error checking for bad input.
# Convert relative path to absolute
# /bin/pwd gets real path without symbolic link on my system and pwd
# keeps symbolic link. You may need to change it to suit your needs.
somedir=`cd $1; /bin/pwd`;
somedirparent=`dirname $somedir`
# Backup directory
/bin/tar cf $somedir.tar $somedir
# Copy, tried move like https://wiki.archlinux.org/index.php/Ramdisk
# suggests, but I got an error.
mkdir -p /mnt/ramdisk$somedir
/bin/cp -r $somedir /mnt/ramdisk$somedirparent
# Remove directory
/bin/rm -r $somedir
# Create symbolic link. It needs to be in parent of given folder.
/bin/ln -s /mnt/ramdisk$somedir $somedirparent
#Run updater
~/bin/rdbackupd "/bin/tar -uf $somedir.tar $somedir" &
uramdir
#!/bin/bash
#Convert relative path to absolute
#somepath would probably make more sense
# pwd and not /bin/pwd so we get a symbolic path.
somedir=`cd $1; pwd`;
# Remove symbolic link
rm $somedir
# Copy dir back
/bin/cp -r /mnt/ramdisk$somedir $somedir
# Remove from ramdisk
/bin/rm -r /mnt/ramdisk$somedir
# Stop
killall rdbackupd
rdbackupd.cpp
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <signal.h>
#include <sys/time.h>
struct itimerval it;
char* command;
void update_archive(int sig)
{
system(command);
}
int main(int argc, char**argv)
{
it.it_value.tv_sec = 1; // Start right now
it.it_value.tv_usec = 0;
it.it_interval.tv_sec = 60; // Run every 60 seconds
it.it_interval.tv_usec = 0;
if (argc < 2)
{
printf("rdbackupd: Need command to run\n");
return 1;
}
command = argv[1];
signal(SIGALRM, update_archive);
setitimer(ITIMER_REAL, &it, NULL); // Start
while(true);
return 0;
}
私たちはこの数年前に 4GL マクロコンパイラで行っていました。マクロライブラリとサポートライブラリ、およびコードをRAMディスクに置くと、アプリケーションのコンパイル（80286上）は20分から30秒になります。
プロファイル。各オプションを適切に測定してください。すでに拒否したものを購入し、測定して返品することもできるので、良いデータから作業していることがわかります。
大量のRAMを取得します。2 GBDIMMは非常に安価です。 4 GBDIMMは1個あたり100米ドル強ですが、それでも数年前のコンピュータ部品の価格と比べるとそれほど多くはありません。最終的にRAMディスクになる場合でも、OSに処理を任せる場合でも、これは役に立ちます。32ビットWindowsを実行している場合は、64ビットに切り替える必要があります。 3GB程度を超えるものを利用するため。
Live Meshは、ローカルのRAMドライブからクラウドまたは別のコンピューターに同期でき、最大で-日付のバックアップ。
コンパイラ出力のみを移動します。ソースコードは実際の物理ディスクに保持しますが、.obj、.dll、および.exeファイルはRAMドライブ。
検討してください [〜＃〜] dvcs [〜＃〜] 。実際のドライブから上の新しいリポジトリにクローンを作成しますRAMドライブ。すべてのテストに合格するたびに、変更を親に「プッシュ」することがよくあります。
私も同じ考えを持っていて、いくつかの調査をしました。私はあなたが探していることをする次のツールを見つけました：
ただし、2つ目は64ビットのWindows 7で動作することができず、現時点では維持されていないようです。
一方、VSuite RAMディスクは非常にうまく機能します。残念ながら、 [〜＃〜] ssd [と比較して大幅なパフォーマンスの向上を測定することはできませんでした。 〜＃〜] ディスクが所定の位置にあります。
ええ、私は同じ問題に遭遇しました。そして、無駄なグーグルの後、私はRAMドライブを怠惰にバックアップするためのWindowsサービスを作成しました（実際には、RAMドライブはデスクトップなどにマウントできるため、任意のフォルダー） 。
http://bitbucket.org/xkip/transparentbackup フルスキャンの間隔を指定できます（デフォルトは5分）。また、通知されたファイルのみをスキャンする間隔（デフォルトは30秒）。スキャンは、「アーカイブ」属性を使用して変更されたファイルを検出します（OSは、アーカイブ目的でファイルをリセットします）。そのように変更されたファイルのみがバックアップされます。
このサービスは、ターゲットのバックアップがソースのバックアップであることを確認するために、特別なマーカーファイルを残します。ソースが空でマーカーファイルが含まれていない場合、サービスはバックアップからの自動復元を実行します。したがって、RAMドライブを簡単に破棄し、自動データ復元を使用して再作成できます。システムの起動時にパーティションを作成できるRAMドライブを使用して、透過的に動作させることをお勧めします。
私が最近検出した別の解決策は SuperSpeed SuperCache です。
この会社にもRAMディスクがありますが、これは別のソフトウェアです。 SuperCacheを使用すると、ブロックレベルのキャッシュに追加のRAMを使用でき（ファイルキャッシュとは大きく異なります）、別のオプションとして、ドライブをRAMに完全にミラーリングします。どのシナリオでも、ダーティブロックをハードディスクドライブにドロップしてRAMドライブのように書き込む頻度を指定できますが、ミラーシナリオではRAMのように読み取りも行います。ドライブ。 2 GB（Windowsを使用）などの小さなパーティションを作成し、パーティション全体をRAMにマッピングできます。
このソリューションの興味深い非常に便利な点の1つは、2回クリックするだけで、いつでもキャッシュとミラーリングのオプションを変更できることです。たとえば、gamimgまたは仮想マシン用に2 GBを元に戻したい場合は、ミラーリングをすぐに停止してメモリを解放するだけです。開いたファイルハンドルでさえ壊れません-パーティションは引き続き機能しますが、通常のドライブとして機能します。
編集：コンパイラは通常tempで多くの作業を行うため、TEMPフォルダをte RAMドライブに移動することも強くお勧めします。私の場合、コンパイル速度がさらに30％向上しました。
周りにはたくさんのRAMDriveがあります。そのうちの1つを使用してください。申し訳ありませんが、それは無謀でしょう。
RAMディスクで完全に作業する場合のみ、これはばかげています。
疑似っぽいシェルスクリプト、ramMake：
# setup locations
$ramdrive = /Volumes/ramspace
$project = $HOME/code/someproject
# ..create ram drive..
# sync project directory to RAM drive
rsync -av $project $ramdrive
# build
cd $ramdrive
make
#optional, copy the built data to the project directory:
rsync $ramdrive/build $project/build
とは言うものの、コンパイラは追加のスクリプトなしでこれを実行できる可能性があります。ビルドの出力場所をRAMディスクに変更するだけです。たとえば、Xcodeでは、[設定]、[ビルド]、[ビルド製品の配置]の下にあります。 in：」および「中間ビルドファイルの配置：」。
物理ディスク/パーティションをメンバーとして持ち、RAM）のチャンクをメンバーとして持つソフトウェアRAID1のようなものを構築できるかどうか疑問に思います。
Linuxにこれを実行させることができる、少しの調整といくつかの本当に奇妙な構成に賭けます。しかし、努力する価値があるとは思いません。
シングルコアマシンでも非常に有益なのは、パラレルメイクです。ディスク I/O は、ビルドプロセスのかなり大きな要素です。 CPUコアごとに2つのコンパイラインスタンスを生成すると、実際にパフォーマンスを向上させることができます。一方のコンパイラインスタンスがI/Oをブロックすると、もう一方は通常、コンパイルのCPUを集中的に使用する部分にジャンプできます。
これをサポートするにはRAM）があることを確認する必要があります（最近のワークステーションでは問題にならないはずです）。そうしないと、スワップしてしまい、目的が果たせなくなります。
GNU make では、-j[n]を使用できます。ここで、[n]はスポーンする同時プロセスの数です。ただし、試してみる直前に依存関係ツリーがあることを確認してください。そうしないと、結果が予測できない可能性があります。
（並列作成方式で）本当に役立つもう1つのツールは、 distcc です。これはGCCで扱います（GCCまたは同様のコマンドラインインターフェイスで何かを使用できる場合）。 distccは実際には、コンパイラのふりをしてリモートサーバーにタスクを生成することにより、コンパイルタスクを分割します。 GCCを呼び出すのと同じ方法で呼び出し、makeの-j [n]オプションを利用して多くのdistccプロセスを呼び出します。
私の以前の仕事の1つでは、かなり集中的なLinuxオペレーティングシステムのビルドがあり、それはしばらくの間ほぼ毎日実行されていました。いくつかの専用ビルドマシンを追加し、コンパイルジョブを受け入れるためにいくつかのワークステーションにdistccを配置することで、完全なOS +ユーザースペースビルドのビルド時間を半日から60分未満に短縮することができました。
コンパイルを高速化するためのツールは他にもたくさんあります。 RAMディスクの作成以上のことを調査することをお勧めします。OSはRAMを使用してディスクキャッシュを実行しているため、ほとんど利益がないように見えます。OS設計者は、キャッシュを正しく行うために多くの時間を費やしていますほとんどのワークロードでは、それらは（集合的に）あなたよりも賢いので、私はそれらよりもうまくやってみたくありません。
RAM for RAM disk、OSはデータをキャッシュしてコードを実行するためのRAM ->スワッピングが多くなり、ディスクのパフォーマンスが低下します（注：このオプションを完全に破棄する前にプロファイルする必要があります）。
この問題に対する私の最終的な解決策はvmtouchです： https://hoytech.com/vmtouch/ このツールは現在のフォルダーを（ram）キャッシュにロックし、vmtouchはバックグラウンドにデーモン化します。
Sudo vmtouch -d -L ./
高速アクセスのためにこれをShellrcに入れてください：
alias cacheThis = 'Sudo vmtouch -d -L ./'
自分のramdisk-rsync-scriptを書くのに多くの時間を無駄にしたくなかったので、私はかなり長い間既製のスクリプトを探しました。重要なコードが含まれていると非常に不快なEdgeのケースを見逃していたと思います。そして、私はポーリングアプローチが好きではありませんでした。
Vmtouchは完璧なソリューションのようです。さらに、固定サイズのRAMディスクのようにメモリを浪費することはありません。 1Gigのsource + buildフォルダーの90％が既にキャッシュされているため、ベンチマークを実行しませんでしたが、少なくとも高速に感じられます;）
発生するディスクの速度低下は主に書き込みであり、ウイルススキャナーが原因である可能性もあります。 OSによっても大きく異なる可能性があります。
書き込みが最も遅いという考えで、中間のビルドをセットアップしたくなるでしょう（たとえば、.oファイル）とバイナリは、RAMドライブなどの別の場所に出力を取得します。
次に、このbin /中間フォルダをより高速なメディアにリンクできます（ シンボリックリンク または NTFSジャンクションポイント を使用）。
これは、オペレーティングシステムやハードドライブが自動的に処理するディスクキャッシュのように聞こえます（確かに、パフォーマンスの程度はさまざまです）。
ドライブの速度が気に入らない場合は、コンパイルのみを目的として高速ドライブを購入することをお勧めします。あなたの側のより少ない労働とあなたはあなたのコンパイルの悩みに対する解決策を持っているかもしれません。
この質問が最初に出されて以来、SSDと比較すると、回転するハードディスクは惨めなカメになっています。これらは、NeweggまたはAmazonから購入できるSKU内の最初に要求されたRAMディスクに非常に近いものです。
私の頭のてっぺんからいくつかのアイデア：
Sysinternals ' Process Monitor （not Process Explorer ）を使用して、ビルド中に何が起こっているかを確認します-これにより、たとえば%temp%が使用されているかどうかを確認できます（応答ファイルはおそらくFILE_ATTRIBUTE_TEMPORARYで作成されているため、可能であればディスクへの書き込みを防ぐ必要があることに注意してください）。 %TEMP%をRAMディスクに移動しました。これにより、一般的にマイナーなスピードアップが得られます。
ディスクイメージの自動ロード/保存をサポートするRAMディスクを取得するため、これを行うためにブートスクリプトを使用する必要はありません。単一のディスクイメージの順次読み取り/書き込みは、同期するよりも高速です。小さなファイルがたくさん。
頻繁に使用する/大きなヘッダーファイルをRAMディスクに配置し、コンパイラの標準パスを上書きしてRAMドライブコピーを使用します。 thatただし、OSが標準ヘッダーをキャッシュするため、初回ビルド後の大幅な改善。
ソースファイルをハードドライブに保存し、RAMディスク-と同期します。その逆ではありません）。チェックアウト MirrorFolder フォルダ間でリアルタイム同期を行う場合-フィルタドライバを介してこれを実現するため、必要なものだけを同期します（変更のみを行います-2GBファイルへの4KBの書き込みでは4KBのみが発生しますターゲットフォルダに書き込みます）。 [〜＃〜] ide [〜＃〜] ビルドをRAMドライブから作成しますが、ソースファイルはハードディスク上に...そして、大規模なプロジェクトにはlargeRAMドライブが必要になることに注意してください。