LRU 文件缓存以及在 Windows 目录中查找文件的成本
我有一个应用程序，可以下载并缓存至少 250,000 个 8KB* 文件，总计约 2GB。更新此缓存时，我需要删除最近最少使用的文件。 *这些小文件跨越两个 4KB 扇区。
在 NTFS 格式的 5400 RPM 驱动器上的目录中按名称获取此类文件的文件句柄的相对成本是多少？如果我将所有 200K 文件存储在一个目录中，仅获取文件句柄就需要几毫秒以上的时间吗？我可以轻松地将文件存储到不同的目录中。
Windows 7默认禁用文件的最后访问时间，我不想要求管理员启用此功能。我是否应该在内存中维护一份单独的文件访问时间列表（当应用程序退出时序列化到磁盘？）
我是否应该考虑将这些文件存储在一个大的平面文件中？如果我使用 .NET 4.0 之前的版本，内存映射可能会很困难
I have an application that will download and cache, at a minimum, 250,000 8KB* files totaling about 2GB. I need to remove the least recently used file when updating this cache. *These tiny files span two 4KB sectors.
What is the relative cost of obtaining a file handle by name for this type of file in a directory on an NTFS-formatted 5400 RPM drive? If I store all 200K files in one directory will merely getting a file handle take more than a few milliseconds? I can easily bucket the files into different directories.
Windows 7 disables the last access time for files by default, and I don't want to require an administrator to enable this feature. Should I maintain a separate list of file access times in memory (serialized to disk when the app exits?)
Should I consider storing these files in one large flat file? Memory mapping might be difficult if I use anything older than .NET 4.0
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
打开 250,000 个文件（如果这就是您的意思）将花费超过几毫秒的时间，是的。目录的大小并不重要，重要的是您要遍历整个文件系统堆栈 250,000 次（来自 NTFS、内核和您祖母最喜欢的防病毒过滤器的所有内容都必须有机会发挥作用）。
无论如何，最后访问时间并不是绝对可靠的。
Opening 250,000 files -- if that's what you mean -- will take more than a few milliseconds, yes. The size of the directory is less interesting than the fact that you're going through the entire file system stack 250,000 times (everything from NTFS, the kernel, and your grandmother's favorite anti-virus filter all have to get a chance to play).
And last access time isn't rock-solid in any case.
在平均 5400rpm 驱动器上，一次寻道大约需要 15 毫秒。相比之下，其余的都是微不足道的。
One seek is approximately 15ms on an average 5400rpm drive. The rest is minuscule in comparison.