Abusando De XmlReader ReadSubtree()

Question

Es necesario analizar un archivo xml que es prácticamente una imagen de una gran estructura de árbol, así que estoy usando la clase XmlReader para rellenar el árbol 'sobre la marcha'.Cada nodo se pasa sólo el xml pedazo él espera de sus padres a través de la ReadSubtree() función.Esto tiene la ventaja de no tener que preocuparse acerca de cuando un nodo ha consumido todos sus hijos.Pero ahora me pregunto si esto es realmente una buena idea, como no podía ser de miles de nodos y durante la lectura de el .Fuente NETA de archivos he encontrado que una pareja (y probablemente más) se crean nuevos objetos con cada ReadSubtree llamada, y sin almacenamiento en caché de objetos reutilizables (los que he visto).

Tal vez ReadSubtree() no estaba pensado para ser masivamente utilizado, o tal vez estoy preocuparse por nada y sólo tengo que llamar a la GC.Collect() después de analizar el archivo...

Espero que alguien pueda arrojar algo de luz sobre esto.

Gracias de antemano.

Actualización:

Gracias por la buena y acertadas respuestas.

Yo tenía una mirada más profunda a la .NET de código fuente y me pareció que para ser más compleja que la primera vez me imaginé.Por fin he abandonado la idea de llamar a esta función, en este mismo escenario.Como Stefan señalado, el lector de xml es nunca pasa a los de afuera y que puedo confiar en el código que analiza la secuencia xml, (el cual está escrito por mí), así que prefiero la fuerza de cada nodo para ser responsable de la cantidad de datos que se roban de la corriente de que el uso de la no-tan-finos-en-la-final ReadSubtree() función para guardar sólo un par de líneas de código.

Answer 1

ReadSubTree() le da un XmlReader que envuelve el original XmlReader.Este nuevo lector aparece a los consumidores como un documento completo.Esto puede ser importante si el código de pasar el subárbol que piensa que es conseguir un independiente documento xml.Por ejemplo, la Profundidad de la propiedad de la nueva Lector empieza en 0.Es un bonito envoltorio, así que no va a usar más recursos de lo que usted haría si usted utiliza el original XmlReader directamente, En el ejemplo que usted dio, es muy probable que usted no es realmente mucho de el subárbol lector.

La gran ventaja en tu caso sería que el subárbol lector no puede accidentalmente leer más allá del subárbol.Desde el subárbol lector no es muy caro, que la seguridad puede ser suficiente, aunque generalmente es más útil cuando usted necesita el subárbol a parecerse a un documento o no se confía en el código para leer sólo su propio subárbol.

Como Se señaló, usted nunca quiere llamar a la GC.Collect().Nunca va a mejorar el rendimiento.

Answer 2

Haciendo la suposición de que todos los objetos se crean en el normal montón administrado, y no el montón de objetos grandes (es decir, menos de 85k), realmente no debería ser un problema aquí, esto es lo que la GC fue diseñado para tratar con.

Yo sugeriría que, además, no es necesario llamar a la GC.Recoger al final del proceso, como en casi todos los casos, permitiendo que la GC para programar las colecciones de sí mismo le permite trabajar en forma óptima (ver este blog para una explicación muy detallada de GC que lo explica mucho mejor que yo).