Reverse Streamreader

我有一个应用程序，我一直负责清理后。应用程序本身相对简单 - 它运行SQL查询，使用Web服务，并将结果传送到日志文件。我的工作是在应用程序完成后将文件存档到我们的NAS。它专门锁定文件直到完成它们，因此增加了一点复杂性。我也不允许触摸应用程序，只是日志。反正我的应用程序相当简单：Reverse Streamreader

检查文件是否可以打开（赶上IOException异常），并把它划掉一个布尔[]如果没有异常被抛出访问。
浏览标记为true的文件数组，使用ReadLine方法将文件的每一行读入StreamReader。由于应用程序偶尔打嗝并且没有完成，我不能简单地使用IOException来判断文件是否完成 - 我必须实际解析文本。
如果找到指示完成的文本，则压缩文件，将存档文件加载到NAS中，然后删除原件。

我的代码工作，它只是非常耗时（每个日志文件大约500 MB）。我对改进的想法包括从文件底部开始搜索，而不是从顶部开始搜索，但StreamReader不支持这种方法。我不能使用ReadToEnd方法，然后反向读取，因为这只会引发内存不足异常。任何想法，我可以加快解析日志文件？

来源

2010-06-04 monkeyninja

你知道解析文件是缓慢的部分代码来完成？没有ziping，复制到NAS，删除或尝试打开文件（并可能失败）所有这些事情听起来像他们可能需要一段时间 – luke 2010-06-04 17:27:05

可能dupe：http://stackoverflow.com/questions/452902/how-to-read -a-text-file-reversely-with-iterator-in-c – 2010-06-04 17:36:12

好问题。是的，这绝对是解析，这是执行的耗时部分。我将代码分成单独的函数并在每个函数上放置断点。压缩需要大约30-45秒，解析可能需要两个多小时。 – monkeyninja 2010-06-04 17:50:04

我假设你在文件末尾查找单个标记以确定它是否完成？如果是这样，我还假定标记已知长度，例如单个字节或3个字节的序列等。

如果上述假设是正确的，则可以打开FileStream，Seek到文件末尾减去预期的标记长度读取字节，如果标记存在并完成，则知道可以处理该文件。

寻求到年底-3个字节可以通过类似以下的

// Seek -3 bytes starting from the end of the file 
fileStream.Seek(-3, SeekOrigin.End);

来源

2010-06-04 17:25:06

寻求可能比顺序读取更昂贵的操作，并且做多个搜索可能会非常缓慢。 – josephj1989 2010-06-04 17:36:59

这是我还没有尝试过，所以这是值得一试。我会尝试实施这个寻求，看看它是否能够加快速度。谢谢大家。 – monkeyninja 2010-06-04 17:51:19

@ josephj1989，你是说，阅读一个500MB的文件，一行一行或者内存友好的大块文件直到最后才比单纯地直接查找最快？为什么多次寻求，我所说的假设是，标记是在文件的末尾，所以只有一次搜索。 – 2010-06-04 17:53:43

Reverse Streamreader

回答

相关问题