Злоупотребление XmlReader ReadSubtree()

Question

Мне нужно проанализировать XML-файл, который практически представляет собой изображение действительно большой древовидной структуры, поэтому я использую класс XmlReader для заполнения дерева «на лету».Каждому узлу через функцию ReadSubtree() передается только фрагмент xml, который он ожидает от своего родителя.Преимущество этого подхода заключается в том, что не нужно беспокоиться о том, когда узел израсходует все свои дочерние узлы.Но теперь мне интересно, действительно ли это хорошая идея, поскольку узлов могут быть тысячи, и при чтении исходных файлов .NET я обнаружил, что при каждом вызове ReadSubtree создается пара (а возможно, и больше) новых объектов, и кеширование для повторно используемых объектов не производится (что я видел).

Возможно, ReadSubtree() не предполагалось массово использовать, или, может быть, я просто зря волнуюсь, и мне просто нужно вызвать GC.Collect() после анализа файла...

Надеюсь, кто-то сможет пролить свет на это.

Заранее спасибо.

Обновлять:

Спасибо за хорошие и содержательные ответы.

Я более внимательно изучил исходный код .NET и обнаружил, что он более сложен, чем я мог себе представить.Я окончательно отказался от идеи вызова этой функции именно в таком сценарии.Как отметил Стефан, программа чтения xml никогда не передается посторонним, и я могу доверять коду, который анализирует поток xml (который написан мной), поэтому я бы предпочел заставить каждый узел нести ответственность за объем данных, которые он передает. украсть из потока, чем использовать не такую ​​уж и тонкую функцию ReadSubtree(), чтобы просто сохранить несколько строк кода.

Answer 1

ReadSubTree() предоставляет вам XmlReader, который оборачивает исходный XmlReader.Это новое устройство чтения представляется потребителям как полноценный документ.Это может быть важно, если код, которому вы передаете поддерево, думает, что он получает отдельный XML-документ.Например, свойство Depth нового Reader начинается с 0.Это довольно тонкая оболочка, поэтому вы не будете использовать больше ресурсов, чем если бы использовали исходный XmlReader напрямую. В приведенном вами примере вполне вероятно, что вы на самом деле не получаете многого от поддерева. читатель.

Большим преимуществом в вашем случае будет то, что программа чтения поддерева не сможет случайно прочитать поддерево.Поскольку программа чтения поддерева не очень дорогая, такой безопасности может быть достаточно, хотя, как правило, она более полезна, когда вам нужно, чтобы поддерево выглядело как документ, или вы не доверяете коду для чтения только своего собственного поддерева.

Как заметил Уилл, вы никогда не захотите вызывать GC.Collect().Это никогда не улучшит производительность.

Answer 2

Если предположить, что все объекты создаются в обычной управляемой куче, а не в куче больших объектов (т. е. менее 85 КБ), здесь действительно не должно быть проблем, это именно то, для чего был разработан GC.

Я бы предположил, что нет необходимости вызывать GC.Collect в конце процесса, поскольку почти во всех случаях разрешение сборщику мусора самому планировать сборы позволяет ему работать оптимальным образом (см. этот пост в блоге за очень подробное объяснение GC, которое объясняет это гораздо лучше, чем я).