INFO: O desempenho de transformações em XSLT no .NET Framework

Traduções deste artigo Traduções deste artigo
ID do artigo: 325689 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

Neste artigo

Sumário

Este artigo contém informações sobre o causas e soluções ou soluções alternativas para problemas de desempenho conhecidos que podem ocorrer quando você usa o processador XSLT do .NET Framework para executar XSLT transformações.

Transformações em XSLT com XmlDataDocument executar lentamente

Aplicar uma transformação XSLT à representação XML dos dados em um DataSet do ADO.NET é um requisito de aplicativo comum. O Microsoft .NET Framework base classes nos namespaces System.XML são usados em conjunto com o DataSet do ADO.NET para implementar esse requisito em aplicativos. NET.

System.Xml.Xsl.XslTransform é a classe base do .NET Framework que é usada para executar XSLT transformações. System.Xml.XmlDataDocument System.XML.XmlDocument e System.Xml.XPath.XPathDocument são as classes .NET Framework base três que podem ser usadas para carregar e fornecer a representação XML dos dados em um DataSet do ADO.NET como a origem XML quando uma transformação XSLT é executada. Uma dessas três opções, usando um objeto XmlDataDocument requer o código menos porque pode ser sincronizado diretamente com um objeto DataSet quando é instanciado. No entanto, um desempenho lento é um problema comum quando você usa um objeto XmlDataDocument para aplicar uma transformação XSLT a representação XML de um DataSet do ADO.NET. Esse comportamento é próprio do projeto na versão RTM do .NET Framework.

System.Xml.XPath.XPathDocument é a classe mais otimizada para processamento de XPath e XSLT. Carregue a representação XML dos dados DataSet em um objeto XPathDocument e fornecer o objeto XPathDocument como o XML de origem quando você executa uma transformação XSLT para obter desempenho máximo. Para obter informações adicionais sobre esse problema e para obter um exemplo de código que demonstra como implementar a solução descrita, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
318580PROBLEMA: Transformações de XSL com XmlDataDocument podem executar mais lentamente do que XPathDocument

Desempenho lento quando Transforming um DataSet com não aninhado objetos DataRelation

Desempenho lento é esteja relacionado com um problema comum quando você tenta transformar a representação XML de um DataSet que possui vários objetos DataTable e cujos objetos DataRelation não tem sido aninhados para refletir uma estrutura hierárquica para descrever as relações no XML serializado.

Quando você tenta transformar esses dados XML em um formato hierárquico diferente (como um HTML tabela que exibe os dados em uma hierarquia pai-filho), você deve usar o XPath eixos de caminho de local, como irmão anterior que podem diminuir a transformação e irmão seguinte processam quando você tem mídia para grandes volumes de dados.

Em tais situações, a Microsoft recomenda que você aninhe os objetos DataRelation do DataSet (que é, definida a propriedade Nested de DataRelation para True ) e escreve o código na folha de estilos XSLT usa natural superior hierárquicas expressões de consulta XPath para localizar e transformar os dados.Para obter informações adicionais, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
325693PROBLEMA: Desempenho lento quando Transforming um ConjuntoDeDados ADO.NET com não Nested DataRelations

100 Por cento da CPU utilização ou travar quando você usar XmlDocument para executar transformações em XSLT que usar irmão anterior

Usando um objeto XmlDocument para fornecer a fonte XML para uma transformação XSLT que usa os irmão anterior XPath local eixos faz com que 100 % de CPU, que faz com que o computador pare de responder (travar) e também faz com que uma queda steep no desempenho do sistema.

Esse comportamento é notável quando você transformar de médio a grandes documentos XML ou fluxos. No momento, este é um problema conhecido na versão RTM do .NET Framework. A Microsoft está trabalhando para impedir a utilização de CPU de 100 por cento na próxima versão principal do .NET Framework. Aprimorando XmlDocument para coincidir com o desempenho do XPathDocument quando você executar consultas XPath e transformações XSLT não é uma meta de design para versões futuras do .NET Framework.

A classe XPathDocument é a interface recomendada no .NET para carregar o XML quando um aplicativo deve executar consultas XPath ou transformações XSLT nos dados XML. Se você enfrentar esse problema, modifique seu código usar um objeto XPathDocument para fornecer a fonte XML para o processo de transformação do XSLT.

XSL: Key desempenho quando você usar lenta

O elemento XSLT XSL: Key freqüentemente é usado para agrupar dados XML ou identificar ocorrências exclusivas do elemento especificado ou valores de atributo na fonte de XML. Folhas de estilos XSLT que usam o elemento XSL: Key apresentam um desempenho lento quando eles são usados para transformar dados XML em aplicativos .NET. Isso é causado por um problema conhecido na XSLT implementação de processador do elemento XSL: Key na versão RTM do .NET Framework.

Uma correção para solucionar esse problema está disponível no momento. Para obter informações adicionais, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
324478Desempenho lento de XSLT com Parser gerenciado

Gerenciado assemblies gerados para blocos de script de linha não são lançadas corretamente

No .NET Framework, assemblies gerenciados são gerados e implicitamente carregados para executar o código que está contido no <msxsl:script> in-line blocos. Um problema conhecido na versão RTM do .NET Framework impede que esses assemblies de sendo descarregado corretamente quando o processo de transformação for concluído. Este anomalias podem causar um aumento incremental no uso da memória, resultando em uma queda no desempenho do sistema, se a folha de estilo afetado repetidamente for carregada para executar transformações XSLT. A memória unreleased é liberada somente quando o processo de host é reciclado. Para obter informações adicionais, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
316775PROBLEMA: Não é possível descarregar assemblies que você criar e carregar usando o script em XSLT
Para contornar este anomalias no ASP.NET aplicativos, carregar folhas de estilo afetado apenas uma vez durante a vida do aplicativo, armazenar em cache as folhas de estilos no cache do ASP.NET e reutilizar as versões em cache para transformações posteriores. No Windows Forms e projetos de aplicativo de console, você pode usar instâncias de objeto XslTransform globais para carregar as folhas de estilo afetado na inicialização do aplicativo e executar transformações posteriores. Esses métodos de solução alternativa não são aplicáveis quando a transformação do XSLT deve ser executada em um ambiente sem monitoração de estado (por exemplo, da camada intermediária Enterprise Services componentes).

A Microsoft recomenda que você use objetos de extensão XSLT para implementar funções de extensão XPath personalizadas e evitar os efeitos colaterais deste anomalias.

Referências

Para obter informações adicionais, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
313997INFO: Guia para executar transformações XSLT em aplicativos .NET

Propriedades

ID do artigo: 325689 - Última revisão: sexta-feira, 23 de janeiro de 2004 - Revisão: 3.3
A informação contida neste artigo aplica-se a:
  • Bibliotecas de Classes do Microsoft .NET Framework 1.0
  • Bibliotecas de Classes do Microsoft .NET Framework 1.1
Palavras-chave: 
kbmt kbinfo kbxml KB325689 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 325689
Aviso de Isenção de Responsabilidade sobre Conteúdo do KB Aposentado
Este artigo trata de produtos para os quais a Microsoft não mais oferece suporte. Por esta razão, este artigo é oferecido "como está" e não será mais atualizado.

Submeter comentários

 

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