INFORMACIÓN: Rendimiento de transformaciones XSLT en .NET Framework

Seleccione idioma Seleccione idioma
Id. de artículo: 325689 - Ver los productos a los que se aplica este artículo
Expandir todo | Contraer todo

En esta página

Resumen

En este artículo contiene información acerca las causas de y de soluciones o de soluciones para problemas de rendimiento conocidos que puede experimentar cuando usa el procesador de XSLT de .NET Framework para ejecutar XSLT transformaciones.

Transformaciones XSLT con XmlDataDocument realizar lenta

Aplicar una transformación XSLT a la representación XML de los datos de un DataSet de ADO.NET es un requisito común de aplicación. Microsoft .NET Framework se utilizan clases base en los espacios de nombres System.XML junto con el DataSet de ADO.NET para implementar este requisito en aplicaciones .NET.

System.Xml.Xsl.XslTransform es la clase base de .NET Framework que se utiliza para ejecutar XSLT transformaciones. System.Xml.XmlDataDocument , System.Xml.XmlDocument y System.Xml.XPath.XPathDocument son las clases base de .NET Framework tres que pueden utilizarse para cargar y proporcionar la representación XML de los datos de un DataSet de ADO.NET como origen de XML cuando se ejecuta una transformación XSLT. De estas tres opciones mediante un objeto XmlDataDocument requiere el código mínimo porque puede sincronizarán directamente con un objeto DataSet cuando se crea una instancia. Sin embargo, un rendimiento lento es un problema común cuando se utiliza un objeto XmlDataDocument para aplicar una transformación XSLT a la representación XML de un DataSet de ADO.NET. Este comportamiento es por diseño en la versión RTM de .NET Framework.

System.Xml.XPath.XPathDocument es la clase más optimizada para su procesamiento XPath y XSLT. Cargue la representación XML de los datos de DataSet en un objeto XPathDocument y proporcionar el objeto XPathDocument como el código XML de origen cuando se ejecuta una transformación XSLT para obtener el máximo rendimiento. Para información adicional acerca de este problema y obtener un ejemplo de código muestra cómo implementar la solución descrita, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
318580PRB: Transformaciones XSL con XmlDataDocument pueden realizar más despacio que XPathDocument

Rendimiento lento cuando transformar un DataSet con los objetos DataRelation anidados no

Rendimiento lento es relacionado con un problema común cuando intenta transformar la representación XML de un DataSet que tiene varios objetos DataTable y cuyos objetos DataRelation no han sido anidados para reflejar una estructura jerárquica para representar las relaciones en el XML serializado.

Cuando intenta transformar estos datos XML en un formato jerárquico diferente (como HTML de una tabla que muestra los datos de una jerarquía de elementos primarios y secundarios), debe utilizar XPath ejes de la ruta de acceso de ubicación como following-sibling preceding-sibling puede ralentizar la transformación procesan cuando tienes medianas a grandes volúmenes de datos.

En tales situaciones, Microsoft recomienda que anidar los objetos DataRelation del DataSet (que se, establece la propiedad Nested de DataRelation en true ) y escribir código en la hoja de estilos XSLT que usa natural descendente jerárquicas expresiones de consulta de XPath para localizar y transformar los datos.Para obtener información adicional, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
325693PRB: Despacio al transformar un DataSet de ADO.NET con DataRelations anidadas no

100 Por ciento uso de CPU o bloquearse cuando se utilice XmlDocument para ejecutar transformaciones XSLT que usar preceding-sibling

Utilizar un objeto XmlDocument para suministrar el código fuente XML para una transformación XSLT que usa los ejes de ubicación de XPath de precedentes-relacionados hace que la utilización de la CPU del 100 por cien, que hace que el equipo deje de responder (se bloquea) y también produce una colocación empinada en el rendimiento del sistema.

Este comportamiento es apreciable cuando transformar medianas a grandes documentos o secuencias XML. Éste es actualmente un problema conocido en el lanzamiento de RTM de .NET Framework. Microsoft está trabajando para evitar la utilización de CPU al 100 por ciento en la siguiente versión principal de .NET Framework. Mejorar XmlDocument para hacer coincidir el rendimiento de XPathDocument al ejecutar consultas XPath y transformaciones XSLT no es un objetivo de diseño para versiones futuras de .NET Framework.

La clase XPathDocument es la interfaz recomendada en .NET para cargar XML cuando una aplicación debe ejecutar consultas XPath o las transformaciones XSLT en los datos XML. Si experimenta este problema, modifique el código utilizar un objeto XPathDocument para proporcionar el XML de origen para el proceso de transformación de XSLT.

Xsl: Key de rendimiento cuando utiliza lenta

El elemento XSLT de xsl: Key suele utilizarse para agrupar datos XML o identificar apariciones únicas del elemento especificado o valores de atributo en el código XML de origen. Hojas de estilos XSLT que utilice el elemento xsl: Key presentan un rendimiento lento cuando se utilizan para transformar datos XML en aplicaciones .NET. Esto está causado por un problema conocido en el XSLT implementación del procesador del elemento xsl: Key en la versión RTM de .NET Framework.

Actualmente hay una revisión para solucionar este problema. Para obtener información adicional, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
324478Rendimiento de XSLT con Analizador administrado lento

Ensamblados administrados generados para bloques de script no están liberados correctamente

En .NET Framework, los ensamblados administrados se generan y cargar implícitamente a ejecutar el código que se encuentra en línea <msxsl:script> bloques. Un problema conocido en el lanzamiento de RTM de .NET Framework impide que estos ensamblados de está descargando correctamente cuando se completa el proceso de transformación. Esta anomalía puede causar un aumento incremental de uso de memoria, lo que produce una caída en el rendimiento del sistema, si la hoja de estilos afectado repetidamente se carga para ejecutar transformaciones XSLT. Sólo cuando se recicla el proceso de host, se libera la memoria sin liberar. Para obtener información adicional, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
316775PRB: No se puede descargar ensamblados que crear y carga mediante el script en XSLT
Para evitar esta anomalía en ASP.NET aplicaciones, carga el estilo afectado hojas sólo una vez durante la vida de la aplicación, la caché de las hojas de estilo en la caché ASP.NET y reutilizar las versiones en caché para las transformaciones posterior. En formularios Windows Forms y proyectos de aplicación de consola, puede utilizar las instancias de objeto XslTransform globales para cargar las hojas de estilo afectado al iniciarse la aplicación y ejecutar transformaciones posterior. Estos métodos de solución no son aplicables se debe ejecutar la transformación XSLT en un entorno sin estado (por ejemplo, servicios empresariales de nivel medio componentes).

Microsoft recomienda que utilice objetos de extensión XSLT para implementar funciones de extensión de XPath personalizadas y evitar los efectos de esta anomalía.

Referencias

Para obtener información adicional, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
313997INFORMACIÓN: Guía para ejecutar transformaciones XSLT en aplicaciones .NET

Propiedades

Id. de artículo: 325689 - Última revisión: viernes, 23 de enero de 2004 - Versión: 3.3
La información de este artículo se refiere a:
  • Microsoft .NET Framework Class Libraries 1.0
  • Microsoft .NET Framework Class Libraries 1.1
Palabras clave: 
kbmt kbinfo kbxml KB325689 KbMtes
Traducción automática
IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.
Haga clic aquí para ver el artículo original (en inglés): 325689
Renuncia a responsabilidad de los contenidos de la KB sobre productos a los que ya no se ofrece asistencia alguna
El presente artículo se escribió para productos para los que Microsoft ya no ofrece soporte técnico. Por tanto, el presente artículo se ofrece "tal cual" y no será actualizado.

Enviar comentarios

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com