Programmēšana

Vienkāršojiet XML apstrādi ar VTD-XML

3. attēls. Lieli XML faili. Noklikšķiniet uz sīktēla, lai skatītu pilna izmēra attēlu.

Astoņus gadus kopš tās darbības sākuma XML jau ir atvērts kā atvērts, daļēji strukturēts datu formāts datu glabāšanai, kā arī datu apmaiņai tīmeklī. Pateicoties vienkāršībai un cilvēku lasāmībai, XML popularitāte ir strauji pieaugusi lietojumprogrammu izstrādātāju vidū un kļuvusi par neaizstājamu uzņēmuma arhitektūras sastāvdaļu.

Lai gan ir grūti uzskaitīt XML izmantošanas veidu skaitu, par vienu lietu var būt pārliecināts: XML ir jāparsē, pirms kaut ko citu var izdarīt. Patiesībā pareizā parsētāja izvēle bieži ir viens no pirmajiem lēmumiem, kas uzņēmuma izstrādātājiem jārisina savos projektos. Un atkal un atkal šis lēmums attiecas uz diviem populāriem XML apstrādes modeļiem: Document Object Model (DOM) un Simple API for XML (SAX).

No pirmā acu uzmetiena DOM un SAX attiecīgās stiprās un vājās puses šķiet savstarpēji papildinošas: DOM veido atmiņā objektu grafikus; SAX ir balstīts uz notikumiem un neko nesaglabā atmiņā. Tātad, ja dokumenta izmērs ir mazs un datu piekļuves modelis ir sarežģīts, DOM ir pareizais ceļš; pretējā gadījumā izmantojiet SAX.

Tomēr patiesība nekad nav tik vienkārša. Biežāk izstrādātāji nevēlas izmantot SAX tā sarežģītības dēļ, tomēr to dara, jo nav pieejama cita reāla izvēle. Pretējā gadījumā, ja XML faila lielums ir tikai nedaudz lielāks par dažiem simtiem kilobaitu, DOM atmiņas pieskaitāmās daļas un veiktspējas vilkšana kļūst par stingru šķērsli lietojumprogrammu izstrādātājiem, kas neļauj viņiem sasniegt savu projektu minimālos veiktspējas mērķus.

Bet vai SAX tiešām ir daudz labāks? SAX reklamētā parsēšanas veiktspēja - parasti vairākas reizes ātrāk nekā DOM - faktiski bieži maldina. Izrādās, ka neērts, tikai uz priekšu virzāms SAX parsēšanas raksturs prasa ne tikai papildu ieviešanas piepūli, bet arī izpildes sodus, ja dokumenta struktūra kļūst tikai nedaudz sarežģīta. Ja izstrādātāji izvēlas neskenēt dokumentu vairākas reizes, viņiem būs jā buferē dokuments vai jāveido pielāgoti objektu modeļi.

Jebkurā gadījumā veiktspēja cieš, kā to parāda Apache Axis. Savā FAQ lapā Axis apgalvo, ka iekšēji izmanto SAX, lai izveidotu efektīvāku ieviešanu, tomēr tā joprojām izveido savu objektu modeli, kas ir diezgan līdzīgs DOM, kā rezultātā tiek panākti nenozīmīgi veiktspējas uzlabojumi, salīdzinot ar tā priekšgājēju (Apache SOAP). Turklāt SAX nedarbojas labi ar XPath, un kopumā tas nevar vadīt XSLT (Extensible Stylesheet Language Transformation) apstrādi. Tātad, SAX parsējot, tiek reālas XML apstrādes problēmas.

Meklējot vieglāk lietojamu alternatīvu SAX, arvien vairāk izstrādātāju ir vērsušies pie StAX (Streaming API for XML). Salīdzinājumā ar SAX, StAX parsētāji izvelk marķierus no XML failiem, nevis izmanto atzvanīšanu. Lai gan tie ievērojami uzlabo lietojamību, joprojām pastāv pamatjautājumi - StAX tikai uz priekšu analizējamais stils joprojām prasa garlaicīgas ieviešanas pūles un līdz ar to arī slēptās veiktspējas izmaksas.

Apakšējā līnija: Lai jebkurš XML apstrādes modelis būtu plaši noderīgs, tam ir jāatspoguļo XML hierarhiskā struktūra un ne mazāk. Iemesls ir tāpēc, ka XML ir paredzēts sarežģītu datu pārvietošanai tīmeklī, un strukturālās informācijas nodošana ir neatņemama XML darbības sastāvdaļa.

VTD-XML maina spēli

Pieņemsim, ka mums bija jāsāk XML apstrāde no nulles, lai pārvarētu iepriekš minētās problēmas ar DOM un SAX. Jaunajam modelim, iespējams, vajadzētu būt šādām īpašībām:

  • Brīvpieejas iespēja: Apstrādes modelim vajadzētu ļaut izstrādātājam pārvietoties kaut kādā hierarhiskā struktūrā vai nu manuāli, vai, labāk, izmantojot XPath.
  • Augsta veiktspēja: Veiktspējai vajadzētu būt ievērojami labākai nekā DOM un SAX. Un sniegumam jābūt "godīgam", kas nozīmē, ka mērījumam jāietver laiks, kas pavadīts hierarhiskās struktūras izveidošanai.
  • Zems atmiņas patēriņš: Lai padarītu apstrādes modeli piemērojamu plašam scenāriju un failu izmēru diapazonam, tam jāatsniedz visa XML struktūra ar minimālu atmiņas patēriņu.

VTD-XML, kas paredzēts šo mērķu sasniegšanai, ir nākamās paaudzes atklātā pirmkoda XML apstrādes modelis, kas sniedz būtiskus un visaptverošus uzlabojumus salīdzinājumā ar DOM un SAX. Viena no galvenajām VTD-XML optimizācijām ir neekstrahējoša marķēšana. Iekšēji VTD-XML saglabā atmiņā neskartu un nekodētu XML ziņojumu un attēlo marķierus, kuru pamatā ir tikai binārā kodējuma specifikācija, ko sauc Virtāls Tlabi Daprakstītājs. VTD ieraksts ir 64 bitu vesels skaitlis, kas XML kodē marķiera garumu, sākuma nobīdi, veidu un marķiera ligzdošanas dziļumu.

Šeit ir nedaudz VTD-XML vēstures, ja jūs interesē: Pamatkoncepcija tika iecerēta kā veids, kā XML apstrādi veikt īpašā aparatūrā FPGA vai ASIC formā, lai tīkla slēdži un maršrutētāji varētu apstrādāt XML saturu ļoti lielā ātrumā. Vēlāk VTD-XML projekta komanda nolēma atvērt atvērtā koda VTD-XML, un sākotnējā versijas 0.5 izlaišana un Java ieviešana notika 2004. gada maijā. Kopš šīs izlaišanas VTD-XML ir veikti vairāki uzlabojumi un nobriedis ievērojami. Versijā 0.8 VTD-XML C versija tika izlaista kopā ar Java versiju. Iebūvētais XPath atbalsts tika ieviests versijā 1.0 un tika izlaists 2005. gada oktobrī. Jaunākajā versijā 1.5 versija ir pārrakstīts parsēšanas dzinējs, kas ir modulārāks un ar lielāku veiktspēju.

Šajā laidienā ir ieviesta arī funkcija, ko sauc par bufera atkārtotu izmantošanu. Pamatideja ir tāda, ka tad, kad XML lietojumprogrammai, kas atrodas aiz tīkla savienojuma, ir atkārtoti jāapstrādā daudzi ienākošie XML dokumenti, lietojumprogramma faktiski var atkārtoti izmantot atmiņas buferus, kas piešķirti pirmā apstrādes laikā. Citiem vārdiem sakot, vienreiz piešķiriet buferus un izmantojiet tos daudz, daudzas reizes. Īpaši VTD-XML, šī funkcija ļauj pilnībā novērst gan objektu izveidošanu, gan atkritumu savākšanas izmaksas (50-80 procenti no DOM un SAX pieskaitāmajām izmaksām) no XML apstrādes. Projekta vietne satur jaunākās programmatūras lejupielādes un padziļinātu VTD-XML tehnisko aprakstu.

Ātrs piemērs

Lai radītu priekšstatu par VTD-XML programmēšanas stilu, šajā rakstā vispirms tiek salīdzināts kods, izmantojot gan VTD-XML, gan DOM, lai parsētu un pārvietotos vienkāršā XML failā ar nosaukumu test.xml, kura teksta saturs ir parādīts zemāk:

  Zāles pļāvējs 1 148,95 

VTD-XML versija izskatās šādi:

importēt com.ximpleware. *; importēt com.ximpleware.parser. *; importēt java.io. *;

public class use_vtd {public static void main (String [] args) {try {File f = new File ("test.xml"); FileInputStream fis = jauns FileInputStream (f); baits [] ba = jauns baits [(int) f.length ()]; fis.read (ba); VTDGen vg = jauns VTDGen (); vg.setDoc (ba); vg.parse (nepatiesa); VTDNav vn = vg.getNav (); if (vn.matchElement ("purchaseOrder")) {System.out.println ("orderDate ==>" + vn.toString (vn.getAttrVal ("orderDate"))); ja (vn.toElement (VTDNav.FIRST_CHILD, "vienums")) {if (vn.toElement (VTDNav.FIRST_CHILD)) {do {System.out.print (vn.toString (vn.getCurrentIndex ())); System.out.print ("==>");

System.out.println (vn.toString (vn.getText ())); } while (vn.toElement (VTDNav.NEXT_SIBLING)); }}}} catch (izņēmums e) {System.out.println ("noticis izņēmums ==>" + e); }}}

Šīs pašas lietojumprogrammas DOM versija ir parādīta zemāk:

importēt java.io. *; importēt org.w3c.dom. *; importēt org.w3c. *; importēt javax.xml.parsers. *; importēt javax.xml.parsers.DocumentBuilder; importēt javax.xml.parsers.DocumentBuilderFactory; importēt javax.xml.parsers.FactoryConfigurationError; importēt javax.xml.parsers.ParserConfigurationException; importēt org.w3c.dom. *; importēt org.xml.sax.SAXException;

public class use_dom {public static void main (String [] args) {mēģiniet {DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance (); DocumentBuilder parsētājs = factory.newDocumentBuilder (); Dokuments d = parser.parse ("test.xml"); Elementa sakne = d.getDocumentElement (); if (root.getNodeName (). CompareTo ("purchaseOrder") == 0) {System.out.println ("orderDate ==>" + root.getAttribute ("orderDate"));

Mezgls n = root.getFirstChild (); if (n! = null) {do {if (n.getNodeType () == Mezgls.ELEMENT_NODE && n.getNodeName (). salīdzinātTo ("vienums") == 0) {Mezgls n2 = n.getFirstChild (); if (n2! = null) {do {if (n2.getNodeType () == Mezgls.ELEMENT_NODE) ​​{System.out.println (n2.getNodeName () + "==>" + n2.getFirstChild (). getNodeValue ( )); }} while ((n2 = n2.getNextSibling ())! = null); }}} while ((n = n.getNextSibling ())! = null); }}} catch (izņēmums e) {System.out.println ("noticis izņēmums ==>" + e); }}}

Kā parādīts iepriekšējos kodu piemēros, VTD-XML pārvietojas XML hierarhijā, izmantojot uz kursora balstītu API. Turpretī DOM API pārvietojas hierarhijā, pieprasot objektu atsauces. Lūdzu, apmeklējiet projekta VTD-XML vietni, lai iegūtu vairāk tehnisko materiālu un kodu piemērus, kas ļoti dziļi izskaidro VTD-XML.

VTD-XML salīdzinošā novērtēšana

Tālāk salīdzināsim VTD-XML veiktspēju un atmiņas lietojumu ar dažiem populāriem XML parsētājiem. Jāatzīmē, ka lielākā daļa rakstu, kas satur etalonu numurus, piemēram, Denisa Sosnoski (XML Documents on the Run) (JavaWorld, 2002. gada aprīlis), ir no vairākiem gadiem. Kopš tā laika labāka un ātrāka aparatūra ievēro Mūra likumu un kļūst lētāka nekā jebkad agrāk. Tajā pašā laikā XML parsēšana un Java virtuālā mašīna nav stāvējusi uz vietas - viņi ir redzējuši uzlabojumus daudzās galvenajās jomās.

Pārbaudes iestatīšana

Testa platforma ir Sony VAIO klēpjdators, kas aprīkots ar Pentium M 1.7 GHz procesoru (2 MB integrētu L2 kešatmiņu) un 512 MB DDR2 RAM. Priekšējās kopnes frekvence ir 400 MHz. OS ir Windows XP Professional Edition ar 2. pakotni. JVM ir versija 1.5.0_06.

Etalons pārbauda šo XML parsētāju jaunākās versijas:

  • Xerces DOM 2.7.1, ar atliktu mezglu paplašināšanu un bez tā
  • Xerces SAX 2.7.1
  • Pikolo SAX 1.04
  • XPP3 1.1.3.4.O
  • VTD-XML 1.5, ar bufera atkārtotu izmantošanu un bez tā

Testam es izvēlējos lielu dažāda lieluma un strukturālas sarežģītības XML dokumentu kolekciju. Atkarībā no faila lieluma testa dokumenti tiek sagrupēti trīs kategorijās. Mazie faili ir mazāki par 10 KB. Vidēja lieluma failu lielums ir no 10 KB līdz 1 MB. Faili, kas lielāki par 1 MB, tiek uzskatīti par lieliem.

Servera JVM tika izmantots visiem veiktspējas mērījumiem, lai iegūtu maksimālo veiktspēju. Šajos testos etalonu programmas vispirms vairākas reizes veica parsēšanas vai navigācijas rutīnas, lai JVM veica dinamisko, tieši laikā optimizēto baitu kodu, pirms vidējo rādītāju par nākamo atkārtojumu sniegumu kā gala rezultātiem. Lai samazinātu laika izmaiņas diska I / O dēļ, etalona programmas pirms testa palaišanas visus XML failus nolasa atmiņas buferos.

Piezīme: Ieinteresētie lasītāji var lejupielādēt etalona programmu no resursiem.

Parsējot caurlaidspējas salīdzinājumus

Šajā sadaļā ir parādīta XML parsēšanas veiktspēja gan latentumā, gan caurlaidspējā. Ievērojiet, ka, lai arī VTD-XML un DOM ir tieši salīdzināmi, nav godīgi salīdzināt VTD-XML ar SAX vai Pull, jo tie atmiņā neveido nekādu hierarhisku struktūru. Tātad SAX un Pull veiktspēja kalpo tikai kā papildu atskaites punkts.

Caurlaidība

Latentuma salīdzinājumi

1. tabula. Mazie faili

Faila nosaukums / izmērsVTD-XML (ms)VTD-XML bufera atkārtota izmantošana (ms)SAX (ms)DOM (ms)DOM atlikts (ms)Pikolo (ms)Vilkt (ms)
soap2.xml (1727 baiti)0.04460.03460.07820.11220.162250.0920.066
nav_48_0.xml (4608 baiti)0.10540.09280.2660.370.3850.27840.1742
cd_catalog.xml (5035 baiti)0.1180.1080.190.3480.40.20.214
nav_63_0.xml (6848 baiti)0.1490.1350.3540.5130.5570.4840.242
nav_78_0.xml (6920 baiti)0.1530.1420.37040.5880.520.420.29

2. tabula. Vidēji XML faili

$config[zx-auto] not found$config[zx-overlay] not found