Introduction à la méthode de traitement XML émergente VTD-XML

Problèmes

Habituellement, lorsque nous mentionnons l'utilisation de XML, la partie la plus gênante est la verbosité du XML et la vitesse d'analyse du XML. Ce problème devient particulièrement grave lorsque de gros fichiers XML doivent être traités. Ce que je mentionne ici est la manière d'optimiser la vitesse de traitement XML.

Lorsque nous choisissons de traiter des fichiers XML, nous avons généralement deux options :

DOM, qui est le modèle standard du W3C, qui construit les informations structurelles XML sous forme d'arborescence, qui fournit des interfaces et des méthodes. pour parcourir cet arbre.
SAX, un analyseur de bas niveau, effectue un traitement direct élément par élément en lecture seule et ne contient pas d'informations structurelles.
Les deux options ci-dessus ont leurs propres avantages et inconvénients, mais aucune n'est une solution particulièrement bonne. Leurs avantages et inconvénients sont les suivants :

DOM

Avantages : Facilité d'utilisation, car toutes les informations sur la structure XML existent en mémoire et le parcours est simple, prenant en charge XPath.
Inconvénients : la vitesse d'analyse est trop lente, l'utilisation de la mémoire est trop élevée (5x~10x du fichier d'origine) et il est presque impossible de l'utiliser pour des fichiers volumineux.
SAX

Avantages : l'analyse est rapide et l'utilisation de la mémoire n'est pas liée à la taille du XML (cela peut être effectué sans augmenter la mémoire à mesure que XML se développe).
Inconvénients : Mauvaise convivialité car il n'y a pas d'informations structurelles, elles ne peuvent pas être parcourues et ne prennent pas en charge XPath. Si vous avez besoin d'une structure, vous ne pouvez lire qu'un peu et construire un peu, ce qui rend la maintenabilité très mauvaise.
Nous pouvons voir que DOM et SAX sont fondamentalement deux extrêmes opposés, mais aucun des deux ne peut bien répondre à la plupart de nos exigences. Nous devons trouver une autre méthode de traitement. Notez que le problème d'efficacité avec XML n'est pas un problème avec XML lui-même, mais un problème avec l'analyseur qui traite XML, tout comme les deux méthodes que nous avons vues ci-dessus ont des compromis d'efficacité différents.

Réflexion

Nous aimons utiliser des méthodes de type DOM car nous pouvons parcourir, ce qui signifie que XPath peut être pris en charge, ce qui améliore considérablement la facilité d'utilisation, mais l'efficacité du DOM est très faible . Comme nous le savons déjà, le problème d’efficacité réside dans le mécanisme de traitement. Alors, quels aspects du DOM affectent son efficacité ? Faisons une dissection complète :

Dans la plupart des plates-formes actuelles basées sur la technologie des machines virtuelles (hébergées ou tout autre mécanisme similaire), la création et la destruction d'objets sont un travail qui prend du temps (cela vaut la peine de le faire (qui prend beaucoup de temps au Garbage Collection), le grand nombre de créations et de destructions d'objets utilisées dans le mécanisme DOM est sans aucun doute l'une des raisons qui affecte son efficacité (cela entraînera trop de Garbage Collections).
Chaque objet disposera de 32 bits supplémentaires pour stocker son adresse mémoire. Lorsqu'il existe un grand nombre d'objets comme DOM, ce coût supplémentaire n'est pas négligeable.
Le principal problème d'efficacité à l'origine des deux problèmes ci-dessus est que DOM et SAX sont tous deux des modes d'analyse extractive. Ce mode d'analyse est destiné à nécessiter un grand nombre d'objets de création (destruction) pour DOM et SAX, provoquant des problèmes d'efficacité. L'analyse dite extractive signifie que lors de l'analyse XML, DOM ou SAX extraira une partie du fichier original (généralement une chaîne), puis l'analysera et le construira en mémoire (la sortie est naturellement un ou plusieurs objets). Prenons DOM comme exemple. DOM analysera chaque élément, attribut, instruction PRocessing, commentaire, etc. dans un objet et lui donnera une structure. C'est ce qu'on appelle l'analyse extractive.
Un autre problème causé par le problème de l'extraction est l'efficacité des mises à jour. Dans DOM (SAX ne prend pas en charge les mises à jour, nous n'en parlerons donc pas du tout), chaque fois que nous devons apporter des modifications, tout ce que nous avons à faire est de le faire. mettez à jour les informations de l'objet. Ensuite, analysez la chaîne XML. Notez que cette analyse est une analyse complète, c'est-à-dire que le fichier d'origine n'est pas utilisé, mais le modèle DOM est directement ré-analysé complètement dans une chaîne XML. En d'autres termes, DOM ne prend pas en charge la mise à jour incrémentielle (mise à jour incrémentielle).
Un autre "petit" problème qui peut ne pas être remarqué est le codage du XML. Quelle que soit la méthode d'analyse utilisée, elle doit être capable de gérer le codage du XML, c'est-à-dire le décodage lors de la lecture et l'écriture lors de l'écriture. lors du codage. Un autre problème d'efficacité avec DOM est que lorsque je souhaite uniquement apporter une petite modification à un fichier XML volumineux, il doit d'abord décoder l'intégralité du fichier, puis construire la structure. Invisiblement, c'est une autre dépense.
Résumons le problème. En termes simples, le problème d'efficacité du DOM réside principalement dans son mode d'analyse extractive (il en va de même pour SAX, qui a le même problème). Cela a déclenché une série de problèmes connexes. peut être surmonté S'il existe un goulot d'étranglement en matière d'efficacité, il est alors concevable que l'efficacité du traitement XML soit encore améliorée. Si la facilité d'utilisation et l'efficacité du traitement de XML sont grandement améliorées, alors la portée et le modèle d'application de XML seront encore sublimés, et peut-être que de nombreuses choses merveilleuses auxquelles on n'aurait jamais pensé auparavant seront produites.

La solution

VTD-XML est la réponse donnée après avoir réfléchi aux problèmes ci-dessus. C'est un analyseur XML non extractif. En raison de son excellent mécanisme, c'est une bonne solution (. à éviter ) résout les différents problèmes soulevés ci-dessus, et apporte également « accessoirement » d'autres avantages non extractifs, tels qu'une analyse et un parcours rapides, la prise en charge de XPath, la mise à jour incrémentielle, etc. J'ai ici un ensemble de données, tirées du site officiel de VTD-XML :

La vitesse d'analyse de VTD-XML est 1,5x ~ 2,0x celle de SAX (avec gestionnaire de contenu NULL). Avec le gestionnaire de contenu NULL, cela signifie qu'aucune logique de traitement supplémentaire n'est insérée dans l'analyse SAX, ce qui correspond à la vitesse maximale de SAX.
L'utilisation de la mémoire de VTD-XML est 1,3x~1,5x celle du XML d'origine (la partie 1,0x est le XML d'origine et la partie 0,3x~0,5x est la partie occupée par VTD-XML), tandis que l'utilisation de la mémoire du DOM est de 1,3 à 1,5 fois celle du XML d'origine, 5 à 10 fois celle du XML. Par exemple, si la taille d'un XML est de 50 Mo, alors la mémoire occupée par VTD-XML sera comprise entre 65 Mo et 75 Mo, tandis que la mémoire occupée par DOM sera comprise entre 250 Mo et 500 Mo. Utiliser le DOM pour traiter de gros fichiers XML basés sur ces données est une option presque impossible.
Vous trouverez peut-être cela incroyable, est-il vraiment possible de créer un analyseur XML plus facile à utiliser que DOM et plus rapide que SAX ? Ne vous précipitez pas pour conclure, jetons un œil aux principes de VTD-XML !

Principe de base

Comme la plupart des bons produits, le principe du VTD-XML n'est pas compliqué, mais très astucieux. Afin d'atteindre l'objectif de non-extraction, il lit le fichier XML original dans la mémoire inchangé en mode binaire, sans même le décoder, puis analyse la position de chaque élément sur ce tableau d'octets et enregistre certaines opérations de traversée ultérieures. sont effectuées sur ces enregistrements enregistrés Si le contenu XML doit être extrait, la position et d'autres informations dans l'enregistrement sont utilisées pour décoder le tableau d'octets d'origine et renvoyer une chaîne. Tout cela semble simple, mais ce processus simple comporte plusieurs détails de performances et cache plusieurs capacités potentielles. Décrivons d'abord chaque détail de performance :

Afin d'éviter une création excessive d'objets, VTD-XML a décidé d'utiliser le type numérique d'origine comme type d'enregistrement, afin que le tas ne soit pas nécessaire. Le mécanisme d'enregistrement de VTD-XML est appelé VTD (Virtual Token Descriptor). VTD résout le goulot d'étranglement des performances lors de l'étape de tokenisation, ce qui est vraiment une approche intelligente et réfléchie. VTD est un type numérique de 64 bits qui enregistre des informations telles que la position de départ (décalage), la longueur (longueur), la profondeur (profondeur) et le type de jeton (type) de chaque élément.
Notez que VTD est de longueur fixe (il a été officiellement décidé d'utiliser 64 bits). Le but est d'améliorer les performances. Parce que la longueur est fixe, elle est extrêmement efficace (O(1)) lors de la lecture, des requêtes et d'autres opérations. , c'est-à-dire que VTD peut être organisé en utilisant une structure efficace telle que des tableaux, ce qui réduit considérablement les problèmes de performances causés par l'utilisation massive d'objets.
Le super pouvoir de VTD (sans aucune exagération) est qu'il peut simplement transformer une structure de données arborescente telle que XML en une opération sur un tableau d'octets, n'importe quelle opération que vous pouvez imaginer sur un tableau d'octets. Tout peut être appliqué à XML. En effet, le XML lu est binaire (tableau d'octets) et le VTD enregistre l'emplacement de chaque élément et d'autres informations d'accès. Lorsque nous trouvons le VTD à utiliser, nous n'avons besoin que d'utiliser des informations telles que le décalage et la longueur. opération sur le tableau d'octets d'origine, ou vous pouvez opérer directement sur le VTD. Par exemple, si je veux rechercher un élément dans un grand XML et le supprimer, il me suffit alors de trouver le VTD de cet élément (la méthode de traversée sera discutée plus tard), de supprimer ce VTD du tableau VTD, puis d'utiliser all Écrivez simplement le VTD dans un autre tableau d'octets. Étant donné que le VTD supprimé marque l'emplacement de l'élément à supprimer, cet élément n'apparaîtra pas dans le tableau d'octets nouvellement écrit. Utilisez VTD pour écrire le nouveau Le tableau d'octets est en fait une copie de. le tableau d'octets, et son efficacité est assez élevée. C'est ce qu'on appelle la mise à jour incrémentielle.
Concernant la méthode de traversée de VTD-XML, elle utilise LC (Location Cache), qui est simplement une structure de table arborescente construite avec VTD en fonction de sa profondeur en standard. L'entrée de LC est également un type numérique de 64 bits. Les 32 premiers bits représentent l'index d'un VTD et les 32 derniers bits représentent l'index du premier enfant de ce VTD. Vous pouvez utiliser ces informations pour calculer n'importe quelle position que vous souhaitez atteindre. Pour les méthodes de traversée spécifiques, veuillez vous référer à l'article sur le site officiel. Il est compréhensible que VTD-XML basé sur cette méthode de parcours ait des interfaces de fonctionnement différentes de celles du DOM, et cette méthode de parcours de VTD-XML peut vous amener à l'endroit dont vous avez besoin en un minimum d'étapes, les performances de parcours sont très exceptionnelles.

Résumé

Comme vous pouvez le voir ci-dessus, VTD-XML a des fonctionnalités fascinantes, et maintenant la version 1.5 a ajouté la prise en charge de XPath (tant qu'il peut être parcouru, il peut prendre en charge XPath , ce n'est qu'une question de temps :-)), sa praticité a dépassé la portée de ce que nous imaginons aujourd'hui. Un autre super pouvoir de VTD-XML est que, sur la base de sa méthode de traitement actuelle, il peut pleinement prendre en charge le futur standard Binary XML et pousser l'application de XML à un niveau supérieur grâce à la binaryisation ! C'est ce que j'attends avec impatience maintenant ! :-)

Cependant, VTD-XML a encore de nombreux domaines qui doivent être améliorés et perfectionnés, et cet aspect mérite nos efforts et nos discussions.

Ce qui précède est l'introduction de la méthode de traitement XML émergente VTD-XML. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !