INFORMATIONS : les performances de transformations XSLT dans le .NET Framework

Traductions disponibles Traductions disponibles
Numéro d'article: 325689 - Voir les produits auxquels s'applique cet article
Agrandir tout | Réduire tout

Sommaire

Résumé

Cet article contient des informations sur les causes d'et solutions ou solutions des problèmes de performances connus que vous pouvez rencontrer lorsque vous utilisez le processeur de .NET Framework XSLT pour exécuter la transformation XSLT transformations.

Transformations XSLT avec XmlDataDocument effectuer lentement

Appliquer une transformation XSLT à la représentation XML des données dans un DataSet ADO.NET est nécessaire application courantes. Microsoft .NET Framework classes de base dans les espaces de noms System.XML sont utilisées conjointement avec le ADO.NET DataSet pour implémenter cette exigence dans les applications .NET.

System.Xml.Xsl.XslTransform est la classe de .NET Framework de base qui est utilisée pour exécuter XSLT transformations. System.Xml.XmlDataDocument , System.Xml.XmlDocument et System.Xml.XPath.XPathDocument sont les classes .NET Framework base trois qui peuvent servir à charger et de fournir la représentation XML des données dans un DataSet ADO.NET en tant que source XML lorsqu'une transformation XSLT est exécutée. De ces trois options, à l'aide d'un objet XmlDataDocument nécessite le code moins car elle peut être synchronisée directement avec un objet DataSet lorsqu'il est instancié. Cependant, baisse des performances ne courants posent de lorsque vous utilisez un objet XmlDataDocument pour appliquer une transformation XSLT à la représentation XML du an ADO.NET DataSet problème. Ce comportement est par la conception de la version RTM du .NET Framework.

System.Xml.XPath.XPathDocument est la classe plus optimisée pour le traitement XPath et XSLT. Chargez la représentation XML des données de DataSet dans un objet XPathDocument et fournir l'objet XPathDocument en tant que source XML lorsque vous exécutez une transformation XSLT pour obtenir des performances optimales. Pour plus d'informations sur ce problème et pour un exemple de code montre comment implémenter la solution décrite, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
318580 MODÈLE : transformations XSL avec XmlDataDocument peuvent exécuter plus lentement que XPathDocument

Ralentir les performances lors de la transformation d'un DataSet avec des objets DataRelation non imbriqués

Ralentissement des performances sont lié d'un problème courant lorsque vous essayez de transformer la représentation XML d'un DataSet contenant plusieurs objets DataTable et dont objets DataRelation n'ont pas été imbriqués pour refléter une structure hiérarchique pour représenter les relations dans le XML sérialisé.

Lorsque vous essayez de transformer ces données XML dans un format hiérarchique différent (tel que HTML une table qui affiche les données dans une hiérarchie parent-enfant), vous devez utiliser une expression XPath traiter les axes de chemin d'accès emplacement comme frère de suivante et preceding-sibling qui peut ralentir la transformation lors de l'avoir moyennes à grande volumes de données.

Dans ce cas, Microsoft recommande que vous imbriquez les objets DataRelation du DataSet (lequel, la propriété imbriqué du DataRelation la valeur True ) et écrivez du code dans la feuille de style XSLT qu'utilise naturel de haut en bas hiérarchiques expressions de requête de XPath pour localiser et transformer les données. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
325693 MODÈLE : lenteur des performances lors de la transformation d'un DataSet ADO.NET avec DataRelations non imbriquées

100 % Taux d'utilisation du processeur ou se bloquer lorsque vous utilisez XmlDocument pour exécuter les transformations XSLT qui utiliser preceding-sibling

Avec un objet XmlDocument pour fournir la source XML pour une transformation XSLT qui utilise les axes d'emplacement XPath preceding-sibling provoque UC de 100 %, qui l'ordinateur cesse de répondre (se bloquer) et également entraîne un dépôt steep les performances du système.

Ce comportement est perceptible lors de la transformation de taille moyenne à grandes documents XML ou des flux de données. C'est actuellement un problème connu dans la version RTM de .NET Framework. Microsoft travaille pour empêcher l'utilisation de processeur 100 pour cent dans la prochaine version majeure de .NET Framework. Amélioration XmlDocument à rapprocher les performances de XPathDocument lors vous exécutez des requêtes XPath et transformations XSLT n'est pas un objectif de conception pour les versions ultérieures de .NET Framework.

La classe XPathDocument est l'interface recommandée dans .NET pour charger XML lorsqu'une application doit exécuter des requêtes XPath ou des transformations XSLT sur les données XML. Si vous rencontrez ce problème, modifier votre code pour utiliser un objet XPathDocument pour fournir la source XML pour le processus de transformation XSLT.

Xsl:key performances lorsque vous utilisez lente

L'élément XSLT xsl:key est fréquemment utilisé pour regrouper les données XML ou identifier des occurrences uniques d'élément spécifié ou des valeurs d'attribut de la source XML. Feuilles de style XSLT qui utiliseront l'élément xsl:key présentent ralentissement des performances lorsqu'elles sont utilisées pour transformer des données XML dans les applications .NET. Cela est dû à un problème connu dans la transformation XSLT implémentation de processeur de l'élément xsl:key dans la version RTM de .NET Framework.

Un correctif pour résoudre ce problème est actuellement disponible. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
324478 Ralentir les performances XSLT avec l'analyseur géré

Assemblys gérés générés pour les blocs de script en ligne sont non lancées correctement

Dans le .NET Framework, assemblys gérés sont générés et charger implicitement pour exécuter le code qui est contenu dans <msxsl:script> en ligneblocs. Un problème connu dans la version RTM de .NET Framework empêche ces assemblys à partir de correctement déchargé lorsque le processus de transformation est terminé. Cette anomalie peut entraîner une augmentation incrémentielle dans Utilisation de mémoire, ce qui un déroulement des performances du système, si la feuille de style concerné est chargée à plusieurs reprises pour exécuter les transformations XSLT. La mémoire unreleased est libérée uniquement lorsque le processus ordinateur hôte est recyclé. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
316775 MODÈLE : ne peut pas décharger assemblys vous créer et charge à l'aide de script dans XSLT
Pour contourner cette anomalie dans ASP.NET applications, charge le style concerné ne feuilles qu'une seule fois au cours de la durée de vie de l'application, mettre en cache les feuilles de style dans le cache ASP.NET et réutiliser les versions mis en cache pour les transformations ultérieure. Dans Windows Forms et les projets d'application de console, vous pouvez utiliser instances d'objet XslTransform globales pour charger les feuilles de style affecté au démarrage de l'application et exécuter des transformations ultérieure. Ces méthodes de contournement ne sont pas applicables lorsque la transformation XSLT doit être exécutée dans un environnement sans état (par exemple, au niveau intermédiaire Enterprise Services composants).

Microsoft vous recommande d'utiliser objets d'extension XSLT pour implémenter des fonctions d'extension XPath personnalisées et éviter les effets de côté de cette anomalie.

Références

Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
313997 INFO : programme d'exécution de transformations XSLT dans les applications .NET

Propriétés

Numéro d'article: 325689 - Dernière mise à jour: vendredi 23 janvier 2004 - Version: 3.3
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft .NET Framework Class Libraries 1.0
  • Microsoft .NET Framework Class Libraries 1.1
Mots-clés : 
kbmt kbinfo kbxml KB325689 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 325689
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.
Exclusion de responsabilité concernant les contenus obsolètes dans la Base de connaissances
Cet article concerne des produits pour lesquels Microsoft n'offre plus de support. Il est par conséquent fourni « en l'état » et ne sera plus mis à jour.

Envoyer des commentaires

 

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