我有一个读取XML文件的过程。它使用XMLTextReader类来执行此操作，因为它被认为是一种快速且仅转发的XML解析器/阅读器。

对于1兆字节的测试文件，它的工作效果非常好，但是在实时系统中处理12兆文件时，它完全停止了工作。

除了编写自己的XML阅读器之外，还有其他解决方案吗？这还不是世界末日，但我希望尽可能使用可用的标准组件

解决方案

过去，我遇到过类似的性能问题。我将其追溯到试图针对DTD /模式进行远程解析。你在做这个吗？如果可能，请尝试将XmlTextReader.XmlResolver设置为null。

SAXExpat过去真的很不错。 Expat是XML解析器，几乎是参考实现。我记得用它来读取通过TCP连接发送的一些同步XML文件，有时是很大的文件(大约50mb)，没有任何问题。那是3/4年前的.NET 1.1和非常糟糕的计算机。

取决于工作与从阅读器中获得的收益。我们是否将其放入XML DOM或者与此相关的任何对象模型中？无论使用哪种语言或者库，都会造成很大的内存损失。

也许在1.1中有缺陷，考虑过尝试2.0？我在1.1天内从未使用过XmlTextReader，因此无法担保：但是从2.0开始，它是完美的。

如果问题出在XmlTextReader中，我将感到非常惊讶。

如果我们花几分钟编写一个创建XmlTextReader的测试程序，并仅使用Read()来读取文件中的每个节点，直到到达文档末尾，我敢打赌，我们会发现它会放大文件。 12mb的锉刀像黄油一样用热刀切过。如果遇到此问题，这是我要尝试的第一件事。

因为一旦消除了XmlTextReader作为问题的根源，我们就可以将注意力集中在真正引起问题的原因上，这很可能是处理正在读取的节点的代码，而不是读取节点的代码。

只是一个想法。我们是否要在整个过程中打开数据库事务？如果是这样，请尝试不进行事务处理，或者至少在处理过程中更频繁地进行提交。

我不推荐这样做，但是，如果该软件未出售或者未对外提供，我们可以尝试从Mono引入阅读器，看看是否能解决问题。