Que abusa XmlReader ReadSubtree ()

Question

Eu preciso analisar um arquivo xml que é praticamente uma imagem de uma estrutura de árvore muito grande, por isso estou usando a classe XmlReader para preencher a árvore 'on the fly'. Cada nó é passada apenas o pedaço XML que espera do seu pai através da função ReadSubtree (). Isto tem a vantagem de não ter que se preocupar quando um nó tem consumido todos os seus filhos. Mas agora eu estou querendo saber se esta é realmente uma boa idéia, já que poderia haver milhares de nós e ao ler a fonte .NET arquivos Descobri que um casal (e provavelmente mais) novos objetos são criados com cada chamada ReadSubtree, e nenhum cache de objetos reutilizáveis ??é feita (que eu tinha visto).

Talvez ReadSubtree () não foi pensado para ser usado massivamente, ou talvez eu estou apenas se preocupar por nada e eu só precisa chamar GC.Collect () depois de analisar o arquivo ...

espero que alguém possa lançar alguma luz sobre isso.

Agradecemos antecipadamente.

Update:

Obrigado pelas agradáveis ??e interessantes respostas.

Eu tive um olhar mais profundo do código-fonte .NET e eu achei a ser mais complexa do que eu primeiro imaginado. Eu finalmente abandonou a idéia de chamar essa função, neste mesmo cenário. Como Stefan apontou, o leitor xml nunca é passado para fora e eu posso confiar no código que analisa o fluxo de xml, (que é escrito por mim mesmo), então eu prefiro forçar cada nó a ser responsável pela quantidade de dados que roubar a partir do fluxo de utilizar a função não tão fina-in-the-fim ReadSubtree () para apenas excepto algumas linhas de código.

Answer 1

ReadSubtree () dá-lhe um XmlReader que envolve o XmlReader originais. Este novo leitor aparece aos consumidores como um documento completo. Isso pode ser importante se o código que você passa a subárvore para pensa que está recebendo um documento independente xml. Por exemplo, a propriedade Profundidade do novo leitor começa em 0. É um invólucro muito fina, para que você não vai usar qualquer mais recursos do que você faria se você usou o XmlReader original diretamente, no exemplo que você deu, é em vez provável que você não está realmente ficando muito fora do leitor subárvore.

A grande vantagem no seu caso seria que o leitor subárvore não pode acidentalmente ler além do sub-árvore. Desde o leitor subárvore não é muito caro, que a segurança pode ser suficiente, embora seja geralmente mais útil quando você precisar a subárvore para olhar como um documento ou você não confia o código para somente leitura a sua própria sub.

Como Will observou, você nunca quer chamar GC.Collect (). Isso nunca vai melhorar o desempenho.

Answer 2

Fazendo a suposição de que todos os objetos são criados no heap gerenciado normal, e não heap de objeto grande (ou seja, menos de 85k), não há realmente não deve ser problema aqui, este é apenas o que o GC foi projetado para lidar com eles.

Eu sugeriria que também não há necessidade de chamar GC.Collect no final do processo, como em quase todos os casos, permitindo que o GC para coleções de programação própria lhe permite trabalhar da maneira ideal (ver este post para uma explicação muito detalhada de GC que explica isso muito melhor do que eu).