.net 滥用XmlReader ReadSubtree（）

我需要解析一个xml文件，它实际上是一个非常大的树结构的图像，所以我使用XmlReader类“动态”填充树。每个节点通过ReadSubtree（）函数仅传递它期望从其父节点获得的xml块。这样做的好处是不必担心节点何时消耗了其所有子节点。但现在我想知道这是否真的是个好主意，因为可能有数千个节点，在读取.NET源文件时，我发现每次ReadSubtree调用都会创建一些（可能更多）新对象，并且没有对可重用对象进行缓存（如我所见）

也许ReadSubtree（）没有被大量使用，或者我只是不担心什么，我只需要在解析文件后调用GC.Collect（）

希望有人能对此有所启发

提前谢谢

更新： 谢谢你的回答

我深入研究了.NET源代码，发现它比我最初想象的要复杂。我最终放弃了在这个场景中调用这个函数的想法。正如Stefan指出的那样，xml读取器永远不会传递给外部用户，我可以信任解析xml流的代码（这是我自己编写的），因此我宁愿强制每个节点负责它们从流中窃取的数据量，而不是使用最后不太细的ReadSubtree（）函数只保存几行代码。

ReadSubTree（）提供了一个包装原始XmlReader的XmlReader。这个新的阅读器对消费者来说是一个完整的文档。如果您传递子树的代码认为它得到的是一个独立的xml文档，那么这可能很重要。例如，新读取器的深度属性从0开始。它是一个非常薄的包装器，因此您不会使用比直接使用原始XmlReader更多的资源，在您给出的示例中，很可能您并没有从子树读取器中获得太多

在您的案例中，最大的优势是子树阅读器不会意外地读取子树。因为子树读取器并不昂贵，所以这种安全性可能就足够了，尽管当您需要子树看起来像文档或者您不相信代码只读取它自己的子树时，它通常会更有用

---

正如威尔所指出的，您永远不想调用GC.Collect（）。它永远不会提高性能。

假设所有对象都是在正常的托管堆上创建的，而不是在大型对象堆（即小于85k）上创建的，这里真的应该没有问题，这正是GC设计用来处理的

---

我建议，也不需要在流程结束时调用GC.Collect，因为在几乎所有情况下，允许GC安排收集本身可以使其以最佳方式工作（请参阅对GC的详细解释，该解释比我解释得更好）。

永远不要调用GC.Collect（）。永远。在这种情况下，我不会：）