la complexité algorithmique de parseurs XML / validateurs

voix
14

Je dois savoir comment les performances des différents outils XML (parseurs, validateurs, évaluateurs d'expression XPath, etc.) est affectée par la taille et de la complexité du document d'entrée. Y at-il des ressources là-bas ce document comment le temps CPU et utilisation de la mémoire sont affectées par ... eh bien, quoi? Taille du document en octets? Nombre de nœuds? Et est linéaire de la relation, polynomiale, ou pire?

Mettre à jour

Dans un article dans le magazine IEEE Computer, vol 41 n ° 9, septembre 2008, les auteurs du sondage quatre modèles d'analyse XML populaires (DOM, SAX, StAX et VTD). Ils courent quelques tests de performance très simples qui montrent qu'un-analyseur DOM aura son débit réduit de moitié lorsque la taille du fichier d'entrée est passé de 1-15 à 1-15 Ko Mo, soit environ 1000 fois plus grande. Le débit des autres modèles ne sont pas affectés de manière significative.

Malheureusement, ils n'ont pas effectué des études plus détaillées, telles que l'utilisation débit / mémoire en fonction du nombre de noeuds / taille.

L'article est ici.

Mettre à jour

Je ne pouvais pas trouver un traitement formel de ce problème. Pour ce que ça vaut, je l'ai fait quelques expériences mesurant le nombre de nœuds dans un document XML en fonction de la taille du document en octets. Je travaille sur un système de gestion d'entrepôt et les documents XML sont des documents d'entrepôt typiques, par exemple avis de livraison, etc.

Le graphique ci-dessous montre la relation entre la taille en octets et le nombre de nœuds (qui devrait être proportionnelle à l'encombrement de la mémoire du document selon un modèle de DOM). Les différentes couleurs correspondent à différents types de documents. L'échelle est log / log. La ligne noire est le meilleur ajustement aux points bleus. Il est intéressant de noter que pour tous les types de documents, la relation entre la taille des octets et la taille du noeud est linéaire, mais que le coefficient de proportionnalité peut être très différent.

benchmarks

Créé 28/08/2008 à 07:01
source utilisateur
Dans d'autres langues...                            


4 réponses

voix
3

Si je faisais face à ce problème et ne pouvait pas trouver quoi que ce soit sur Google, je probablement essayer de le faire moi-même.

Quelques trucs « back-de-un-evelope » pour obtenir une idée de là où il va. Mais ce serait un peu besoin de moi d'avoir une idée de la façon de faire un analyseur XML. Pour repères non algorithmiques jeter un coup d'oeil ici:

Créé 28/08/2008 à 07:21
source utilisateur

voix
1

Je pense qu'il ya trop de variables pour arriver à une mesure simple de la complexité, sauf si vous faites beaucoup d'hypothèses.

Un analyseur de style simple SAX doit être linéaire en termes de taille du document et plat pour la mémoire.

Quelque chose comme XPath serait impossible de décrire en termes de juste le document d'entrée car la complexité de l'expression XPath joue un rôle énorme.

De même pour la validation de schéma, un grand, mais simple schéma peut bien être linéaire, alors qu'un schéma plus petit qui a une structure beaucoup plus complexe montrerait moins bonnes performances d'exécution.

Comme pour la plupart des questions de performance la seule façon d'obtenir des réponses précises est de mesurer et de voir ce qui se passe!

Créé 29/08/2008 à 17:54
source utilisateur

voix
1

Rob Walker a raison: le problème ne précise pas suffisamment de détails. Considérant que parseurs (et en ignorant la question de savoir si elles valident), il existe deux types principaux: arbres à base pensent DOM et le streaming / base-événement pense SAX (push) et Stax (traction). Prenant la parole à d' énormes généralités, les approches fondées sur les arbres consomment plus de mémoire et sont plus lents (parce que vous devez terminer l' analyse du document entier), alors que les approches de diffusion en continu / base d'événement consomment moins de mémoire et sont plus rapides. Parseurs à base d' arbres sont considérés comme plus faciles à utiliser en général, bien que Stax a été présentée comme une énorme amélioration (en termes de facilité d'utilisation) sur SAX.

Créé 03/09/2008 à 10:47
source utilisateur

voix
0

Je comptais de charger des fichiers XML très volumineux dans mon application. J'ai posé la question ici sur Stack Overflow: traitement XML le plus rapide possible pour les documents très importants .

Et oui, ce fut la partie analyse syntaxique, qui était le goulot d'étranglement.

J'ai fini par ne pas utiliser parseurs XML du tout. Au lieu de cela, j'analysables caractères un par un de manière aussi efficace que possible pour optimiser la vitesse. Cela a donné lieu à une vitesse de 40 Mo par seconde sur un 3 GHz PC Windows pour la lecture, l'analyse syntaxique et le chargement de la structure de données interne.

Je serais très intéressé à entendre comment les différents modes d'analyse syntaxique XML compare à cela.

Créé 12/01/2009 à 16:44
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more