简单解释一下，在过去几周里，我在尝试从光盘读取数据时，在处理一些.net代码时感到非常烦恼。最简单地说，该程序使用itextsharp来检查PDF文件的页数（如果这很重要的话）。CD驱动器的读取速度极不一致，甚至在反复测试的情况下试图使用相同的代码/光盘进行读取。然后，我有了一点顿悟的时刻。至少有足够多的人来问一些比我更知情的人。
第一次枚举光盘上的文件似乎比随后的迭代要花很多时间。然后我意识到，当我第一次读取光盘上的数据时，我的光盘驱动器指示灯会亮起，但在随后运行相同的数据时（基本上，重新运行程序以查看相同的文件），它不会亮起。并非巧合的是，那些后来的阅读时间要快得多。偶然我的程序以某种方式存储了这些数据，我完全关闭了Visual Studio，检查了任务管理器中的进程等，并重新打开了VS。结果似乎是一样的。打开光驱并重新插入光盘？过程重置（第一次慢速等）
我的假设是Windows中的某个技工？它将光盘数据临时存储在"某个地方"，当您再次调用该数据时，它会使用存储在"某处"的数据，而不是从光盘中读取。从外行的角度来看，当你开始考虑从普通HDD读取信息比从CD读取信息快多少时，这当然是有道理的。我猜这在某些圈子里是常识性的东西，但老实说，我在这种情况下并不怎么使用物理媒体。这通常更像是一个"在本地复制，然后做一些事情"的过程。
所以我的问题是"这是一件事吗？"或者是否有其他疯狂的事情正在发生？如果我的猜测不太离谱，有没有办法更有效地使用这种"缓存"功能？例如，在我尝试读取光盘之前，强制它临时缓存光盘或其他内容？或者任何其他人可能会想到的"最佳实践"之类的想法。如果我能提供任何其他信息，请告诉我。
当然，光盘驱动器与硬盘没有什么不同，只是它们的寻道时间要慢得多。对于两者来说，文件系统缓存都是至关重要的，它保留了以前从驱动器读取的数据的副本。Windows为这个缓存提供了相当大的RAM，在有足够RAM的现代机器上，这很容易达到千兆字节。还有一个核心原因是，在32位操作系统上，整个地址空间的一半专用于操作系统。
因此，不可避免的是，对驱动器的第一次访问会很慢，缓存不可能有可用的数据，应用程序必须等待，直到从磁盘读取数据。这是在机械时间而不是电子时间运行的，对于光驱，您可以听到。光盘是CLV——恒定线速度。磁道离光盘中心越近，光盘必须旋转得越快。非常适合封装密度，非常适合搜索时间。磁盘减速会发出很大的咔嗒声。硬盘也没那么安静。这需要许多毫秒。后续访问非常快，只需从文件系统缓存数据中进行内存到内存的复制，它以内存总线的速度运行。5GB/秒及以上，大约一微秒的恒定开销。