任何编程技术,可移植或特定于NT
和Linux
,可以更快地加载大文件数量的结果吗?我是在'提前',先前,无论你喜欢什么称之为机制,我可以在一个问题中为两个操作系统的代码控制。
每个文件必须完整处理,即完全按大小处理,并按顺序处理其内容。目的是加快一些批处理文件的处理。
答案 0 :(得分:4)
我不知道NT,但Linux上的一个选项就是在你真正需要下一个文件开始早期阅读之前不久使用madvise
MADV_WILLNEED
标志。
或者,一个更便携的选项是简单地在缓冲区处理线程的单独线程中手动执行readahead - 也就是说,读取数据以填充线程A中的X MB缓冲区,尽可能快地处理它在主题B中。
答案 1 :(得分:2)
我不知道类似于madvise()
的Win32(NT)API。
但是,我建议采用一种方法。
首先,将Win32标记FILE_FLAG_SEQUENTIAL_SCAN
传递给CreateFile()
。这将允许Windows操作系统在打开文件后执行更好的文件缓冲。
使用FILE_FLAG_SEQUENTIAL_SCAN
,一旦文件在内存中,您的文件解析器可以更快地运行。与Linux上的madvise()
不同,由于使用了Win32标志,该文件不会在任何早期开始加载到内存中。
接下来,我们需要触发文件开始加载。通过使用ReadFileEx()
结构和OVERLAPPED
函数调用FileIOCompletionRoutine
来异步读取文件的第一页。
您的FileIOCompletionRoutine
可以直接返回,或者您可以在重叠结构中设置事件 - 有关详细信息,请阅读ReadFileEx
的MSDN详细信息。
因为当你实际从文件中读取时预取还没有完成就不会是一个严重的失败,最简单的实现就是“发射并忘记” - 执行重叠文件读取然后再检查结果。但是,请确保将数据读入有效缓冲区!
如果在读取上一个文件时对文件执行此操作,结果应该是下一个文件将开始分页。
请注意,这可能会降低您的表现。当下一个文件开始登录时,访问该文件的磁盘I / O将与您当前正在解析的文件的磁盘I / O竞争。如果两个文件在同一磁盘上彼此物理上相距很远,则预取的结果可能是驱动器磁头寻找时的额外延迟。虽然现代驱动器具有可以缓解这种情况的巨大缓冲区,但排队新文件的第一页可能会引起搜索。
bdonlan建议使用'pre-fetch'线程从处理中异步加载文件,这对Win32来说也是一个可行的解决方案。