caching - 用于编译的RAM驱动器-有这样的事情吗？

An answer (请参见下文)是Stackoverflow上这里的一个问题。我给了我一个很棒的小软件想法，它可能对各地的编码人员都是无价之宝。

我正在想象RAM驱动器软件，但是有一个关键的区别-它会镜像硬盘上的真实文件夹。更具体地说-包含我当前正在处理的项目的文件夹。这样，任何构建都将几乎是瞬时的(或者至少快几个数量级)。 RAM驱动器将仅使用空闲资源在后台将其内容与硬盘驱动器同步。

快速的Google搜索没有发现任何内容，但也许我只是不知道如何使用Google。也许有人知道这样的软件？最好是免费的，但合理的费用也可以。

补充:已经提出了一些解决方案，但我一开始就将其丢弃。它们将是(无特定顺序):

购买更快的硬盘驱动器(也许是SSD或10K RPM)。我不需要硬件解决方案。不仅软件有可能变得更便宜(免费软件，还有其他人吗？)，而且它还可以用在不受欢迎的硬件修改环境中，例如在办公室，这种修改是不受欢迎的。

让OS / HDD进行缓存-它更好地了解如何使用可用的RAM。 OS / HDD具有通用的缓存算法，可以缓存所有内容并尝试预测将来最需要的数据。他们不知道对我来说优先级是我的项目文件夹。众所周知，他们实际上并没有太多地缓存它。 ;)

周围有很多RAM驱动器；使用其中之一。对不起，那将是鲁re的。每当有一点空闲时间时，我都需要将我的数据同步回HDD。如果发生电源故障，我会忍受丢失最后五分钟的工作，但不是自上次登机以来的所有工作。

新增2:提出一个想法-使用普通的RAM驱动器以及后台文件夹同步器(但我的意思是后台)。有这样的事吗？

新增3:有趣。我只是在工作中尝试了一个简单的RAM驱动器。重建时间从〜14秒减少到〜7秒(不错)，但增量构建仍为〜5秒-就像在HDD上一样。有什么想法吗？它使用aspnet_compiler和aspnet_merge。也许他们对其他地方的其他临时文件做了什么？

新增4:哦，很不错的新答案! :)好吧，我为您提供了更多有关反对者的信息。 :)

这个想法的主要原因之一不是上述软件(构建时间为14秒)，而是我当时没有访问权限的另一个软件。此其他应用程序的代码库为100 MB，其完整构建大约需要5分钟。是的，它在Delphi 5中，所以编译器不太高级。 :)将源放在RAM驱动器上会导致很大的差异。我想不到一分钟。我还没测量因此，对于所有那些认为操作系统可以更好地缓存内容的人来说，我希望与众不同。

相关问题:



关于第一个链接的说明:
链接到的问题已被删除，因为它是重复的。它问:



我链接到的Dmitri Nesteruk的答案是:

最佳答案

在Linux中(您从未提到过所使用的操作系统，因此可能很重要)，您可以从RAM中创建块设备并像其他任何块设备(即HDD)一样挂载它们。

然后，您可以创建脚本，这些脚本在启动/关闭时以及周期性地与该驱动器进行复制。

例如，您可以将其设置为~/code和~/code-real。启动时将RAM块安装在~/code上，然后从~/code-real(位于标准硬盘驱动器上)中复制所有内容。在关闭时，所有内容将从~/code复制到~/code-real(rsync将更快)。您可能还希望该脚本定期运行，因此在电源故障等情况下您不会损失太多工作。

我不再这样做了(当9.5 beta变慢时，我就把它用于Opera了，不再需要了)。

Here is how to create a RAM disk in Linux.