C# 反向流阅读器

我有一个应用程序，我一直在清理后的任务。应用程序本身相对简单——它运行SQL查询，使用web服务，并将结果输出到日志文件。我的工作是在应用程序使用完这些文件后，将它们归档到NAS。它以独占方式锁定文件，直到处理完毕，因此增加了一点复杂性。我也不允许触摸应用程序，只允许触摸日志。无论如何，我的应用程序相当简单：

检查文件是否可以打开（catch IOException），如果没有引发异常，则在bool[]中将其标记为可访问

通过标记为true的文件数组，使用ReadLine方法将文件的每一行读入StreamReader。因为应用程序偶尔会打嗝，无法完成，所以我不能简单地使用IOException来判断文件是否已完成-我必须实际解析文本

如果找到指示完成的文本，请压缩文件，将存档文件加载到NAS，然后删除原始文件

---

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

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

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

查找结尾-可以使用如下代码完成3个字节

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

---

你知道解析文件是最慢的部分吗？不使用ziping、复制到NAS、删除或试图打开文件（可能会失败），所有这些听起来都像是他们可能需要一段时间的重复：好问题。是的，解析肯定是执行过程中耗时的部分。我将代码分为单独的函数，并在每个函数上设置断点。压缩大约需要30-45秒，解析可能需要两个小时以上。@monkeynija:你看过我链接的问题了吗？答案有用吗？我有用。它看起来确实可行，我唯一关心的是它的复杂性。在我使用完归档工具后，我将把护理工作交给团队中更初级的成员，因此我试图让实现尽可能简单易懂。查找可能比顺序读取成本更高，并且执行多个查找可能会非常慢。这是我还没有尝试过的事情，尽管如此值得一试。我将尝试实现seek，看看这是否加快了速度。谢谢大家。@josephj1989，你是说逐行读取一个500 MB的文件或内存友好的块直到最后比直接查找到最后要快吗？为什么要进行多次搜索，我的假设是，标记位于文件的末尾，因此只有一次搜索。主要针对来这里寻找已编写的反向线读取器的人：这里有一个由传奇人物Jon Skeet编写的读取器：