问FileStream应用程序非常慢-冷启动

EN

...但是有不同的目标文件设置。

关键短语，您的应用程序将无法利用文件系统缓存。就像第二次测量一样。目录信息不能来自RAM，因为它还没有被读取，操作系统总是必须返回到磁盘驱动器，这是缓慢的。

只有更好的硬件才能加快速度。50毫秒大约是一个主轴驱动器所需的标准时间，20毫秒是这样的驱动器可以走的最低。读者头寻觅时间是机械的硬极限。这是很容易击败今天，SSD是广泛提供和合理的负担得起。唯一的问题是，当你习惯了它，你就再也不搬回来了:)

文件系统和或磁盘控制器将缓存最近访问的文件/扇区。

速率决定步骤是读取文件，而不是构造FileStream对象，当数据在缓存中时，在第二次运行时它将显着地更快是完全正常的。

如前所述，文件系统有自己的缓存机制，这会干扰您的度量。

但是，FileStream构造函数执行几个任务，这是第一次开销很大，需要访问文件系统(因此数据缓存中可能没有)。出于解释的原因，您可以查看代码，并看到CompatibilitySwitches类用于检测子特性的使用情况。与该类一起，反射被大量使用，既直接(用于访问当前程序集)，也间接使用(对于CAS受保护的部分，安全链接要求)。反射引擎有自己的缓存，并要求在自己的缓存为空时访问文件系统。

这两种测量方法如此不同，这让人感到有点奇怪。目前，我们的机器上有一些类似的东西，配备了具有实时保护功能的防病毒软件。在这种情况下，反病毒软件处于中间，缓存第一次被击中或丢失，这取决于这些软件的实现。

由于已知的解码漏洞，反病毒软件可能决定积极检查某些图像文件，如PNG。这种检查会引入额外的减速，并记录最外层的.NET类(即FileStream类)中的时间。

使用本机符号和/或内核调试进行分析，应该会给您更多的了解。

根据我的经验，您所描述的无法减轻，因为我们无法控制多个隐藏层。根据您的使用(我现在还不太清楚)，您可能会在服务中提交应用程序，因此您可以更快地处理所有后续请求。另外，您可以将多个请求分批到一个单独的调用中，以实现摊还降低的成本。