blocks|key|543733|text|文件系统和或磁盘控制器将缓存最近访问的文件/扇区。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|543734|速率决定步骤是读取文件，而不是构造FileStream对象，当数据在缓存中时，在第二次运行时它将显着地更快是完全正常的。|offset|length|style|CODE|543735|entityMap^0|0|H|A|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

The file system and or disk controller will cache recently accessed files / sectors.

The rate-determining step is reading the file, not constructing a <code>FileStream</code> object, and it's completely normal that it will be significantly faster on the second run when data is in the cache.

blocks|key|1135265|text|您应该尝试使用本机FILE_FLAG_SEQUENTIAL_SCAN，为了获得句柄并将其传递给FileStream，您必须调用CreateFile。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1135266|entityMap|0|LINK|mutability|MUTABLE|url|http://support.microsoft.com/default.aspx?scid=kb;EN-US;98756|1|http://msdn.microsoft.com/en-us/library/b6fz1x84.aspx^0|9|P|1B|A|1R|A|9|P|0|1B|A|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]|$9|U|A|V|B|C]]|D|@$9|W|A|X|1|Y]|$9|Z|A|10|1|11]]|E|$]]|$1|F|3|-4|5|6|7|12|8|@]|D|@]|E|$]]]|G|$H|$5|I|J|K|E|$L|M]]|N|$5|I|J|K|E|$L|O]]]]

You should try to use the native <a href="http://support.microsoft.com/default.aspx?scid=kb;EN-US;98756" rel="nofollow noreferrer"><code>FILE_FLAG_SEQUENTIAL_SCAN</code></a>, you will have to pinvoke <code>CreateFile</code> in order to get an handle and pass it to <a href="http://msdn.microsoft.com/en-us/library/b6fz1x84.aspx" rel="nofollow noreferrer"><code>FileStream</code></a>

blocks|key|1135311|text|如前所述，文件系统有自己的缓存机制，这会干扰您的度量。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1135312|但是，FileStream构造函数执行几个任务，这是第一次开销很大，需要访问文件系统(因此数据缓存中可能没有)。出于解释的原因，您可以查看代码，并看到CompatibilitySwitches类用于检测子特性的使用情况。与该类一起，反射被大量使用，既直接(用于访问当前程序集)，也间接使用(对于CAS受保护的部分，安全链接要求)。反射引擎有自己的缓存，并要求在自己的缓存为空时访问文件系统。|offset|length|style|CODE|1135313|这两种测量方法如此不同，这让人感到有点奇怪。目前，我们的机器上有一些类似的东西，配备了具有实时保护功能的防病毒软件。在这种情况下，反病毒软件处于中间，缓存第一次被击中或丢失，这取决于这些软件的实现。|1135314|由于已知的解码漏洞，反病毒软件可能决定积极检查某些图像文件，如PNG。这种检查会引入额外的减速，并记录最外层的.NET类(即FileStream类)中的时间。|1135315|使用本机符号和/或内核调试进行分析，应该会给您更多的了解。|1135316|根据我的经验，您所描述的无法减轻，因为我们无法控制多个隐藏层。根据您的使用(我现在还不太清楚)，您可能会在服务中提交应用程序，因此您可以更快地处理所有后续请求。另外，您可以将多个请求分批到一个单独的调用中，以实现摊还降低的成本。|1135317|entityMap^0|0|3|A|23|L|0|0|1Q|A|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@$D|T|E|U|F|G]|$D|V|E|W|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|Y|8|@$D|Z|E|10|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|11|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|12|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|Q|$]]

As stated earlier, the file system has its own caching mechanism which perturbates your measurement.

However, the <code>FileStream</code> constructor performs several tasks which, the first time are expensive and require accessing the file system (therefore something which might not be in the data cache). For explanatory reasons, you can take a look at the code, and see that the <code>CompatibilitySwitches</code> classes is used to detect sub feature usage. Together with this class, Reflection is heavily used both directly (to access the current assembly) and indirectly (for CAS protected sections, security link demands). The Reflection engine has its own cache, and requires accessing the file system when its own cache is empty. 

It feels a little bit odd that the two measurements are so different. We currently have something similar on our machines equipped with an antivirus software configured with realtime protection. In this case, the antivirus software is in the middle and the cache is hit or missed the first time depending the implementation of such software.

The antivirus software might decide to aggressively check certain image files, like PNGs, due to known decode vulnerabilities. Such checks introduce additional slowdown and accounts the time in the outermost .NET class, i.e. the <code>FileStream</code> class.

Profiling using native symbols and/or with kernel debugging, should give you more insights.

Based on my experience, what you describe cannot be mitigated as there are multiple hidden layers out of our control. Depending on your usage, which is not perfectly clear to me right now, you might turn the application in a service, therefore you could serve all the subsequent requests faster. Alternative, you could batch multiple requests into one single call to achieve an amortized reduced cost.

blocks|key|1170729|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1170730|+...但是有不同的目标文件设置。|blockquote|1170731|1170732|1170733|关键短语，您的应用程序将无法利用文件系统缓存。就像第二次测量一样。目录信息不能来自RAM，因为它还没有被读取，操作系统总是必须返回到磁盘驱动器，这是缓慢的。|1170734|只有更好的硬件才能加快速度。50毫秒大约是一个主轴驱动器所需的标准时间，20毫秒是这样的驱动器可以走的最低。读者头寻觅时间是机械的硬极限。这是很容易击败今天，SSD是广泛提供和合理的负担得起。唯一的问题是，当你习惯了它，你就再也不搬回来了:)|1170735|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|L|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|M|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|N|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|O|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|P|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|Q|7|@]|8|@]|9|$]]|$1|J|3|-4|4|5|6|R|7|@]|8|@]|9|$]]]|K|$]]

<blockquote>
 ... but with different target file set.
</blockquote>

Key phrase, your app will not be able to take advantage of the file system cache. Like it did in the second measurement. The directory info can't come from RAM because it wasn't read yet, the OS always has to fall back to the disk drive and that is slow.

Only better hardware can speed it up. 50 msec is about the standard amount of time needed for a spindle drive, 20 msec is about as low as such drives can go. Reader head seek time is the hard mechanical limit. That's easy to beat today, SSD is widely available and reasonably affordable. The only problem with it is that when you got used to it then you never move back :)

blocks|key|1170750|text|偏离轨道的建议，但这是我做了很多，并得到我们的分析30%25+-+70%25快：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1170751|1170752|缓存|blockquote|1170753|1170754|1170755|1170756|编写另一段代码，以便：|1170757|1170758|迭代所有文件；|unordered-list-item|1170759|计算哈希；以及|1170760|将其存储在另一个索引文件中。|1170761|1170762|现在，不要在应用程序启动时调用FileStream构造函数来计算哈希。相反，打开(预期要大得多)较小的索引文件，并从它读取预先计算的散列。|offset|length|style|CODE|1170763|此外，如果这些文件是日志等文件，这些文件每次在应用程序启动之前都是新创建的，那么在文件创建者中添加代码以使用新创建的文件的哈希更新索引文件。|1170764|这样，应用程序就可以始终只从索引文件读取哈希。|1170765|1170766|我同意HansPassant关于使用SSD使磁盘读取更快的建议。这个答案和他的回答是互补的。您可以实现这两者以最大限度地提高性能。|1170767|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|F|A|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|1A|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|1E|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|1G|8|@]|9|@]|A|$]]|$1|O|3|P|5|N|7|1H|8|@]|9|@]|A|$]]|$1|Q|3|R|5|N|7|1I|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1K|8|@$V|1L|W|1M|X|Y]]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1N|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|1O|8|@]|9|@]|A|$]]|$1|13|3|-4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|16|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]]|17|$]]

Off track suggestion, but this is something that I have done a lot and got our analyses 30% - 70% faster:

<blockquote>
 Caching
</blockquote>

<hr>

Write another piece of code that will:

<ul>
<li>iterate over all the files;</li>
<li>compute the hash; and,</li>
<li>store it in another index file.</li>
</ul>

Now, don't call a <code>FileStream</code> constructor to compute the hash when your application starts. Instead, open the (expectedly much) smaller index file and read the precomputed hash off it.

Further, if these files are log etc. files which are freshly created every time before your application starts, add code in the file creator to also update the index file with the hash of the newly created file.

This way your application can always read the hash from the index file only.

<hr>

I concur with @HansPassant's suggestion of using SSDs to make your disk reads faster. This answer and his answer are complimentary. You can implement both to maximize the performance.

A very similar question has also been asked <a href="https://stackoverflow.com/questions/93590/is-filestream-lazy-loaded-in-net">here on SO</a> in case you are interested, but as we will see the accepted answer of that question is not always the case (and it's never the case for my application use-pattern).

The performance determining code consists of FileStream constructor (to open a file) and a SHA1 hash (the .Net framework implementation). The code is pretty much C# version of what was asked in the question I've linked to above.

Case 1: The Application is started either for the first time or Nth time, but with different target file set. The application is now told to compute the hash values on the files that were never accessed before.

<ul>
<li>~50ms</li>
<li>80% FileStream constructor</li>
<li>18% hash computation</li>
</ul>

Case 2: Application is now fully terminated, and started again, asked to compute hash on the same files:

<ul>
<li>~8ms</li>
<li>90% hash computation</li>
<li>8% FileStream constructor</li>
</ul>

Problem 
My application is always in use Case 1. It will never be asked to re-compute a hash on a file that was already visited once.

So my rate-determining step is FileStream Constructor! Is there anything I can do to speed up this use case?

Thank you.

P.S. Stats were gathered using JetBrains profiler.

FileStream very slow on application-cold start

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

在您感兴趣的情况下，也向提出了一个非常类似的问题，但正如我们将要看到的，这个问题的公认答案并不总是这样(我的应用程序使用模式从来没有这样的情况)。性能决定代码由FileStream构造函数(打开文件)和SHA1哈希( .Net框架实现)组成。该代码基本上是我在上面链接到的问题中所问到的问题的C#版本。案例1:应用程序第...

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

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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