Ohjelmointi

Yksinkertaista XML-käsittelyä VTD-XML: llä

Kuva 3. Suuret XML-tiedostot. Napsauta pikkukuvaa nähdäksesi täysikokoisen kuvan.

Kahdeksan vuotta perustamisestaan ​​XML on jo aloittanut avoimen, osittain strukturoidun datamuodon tietojen tallentamiseksi ja tietojen vaihtamiseksi verkossa. Yksinkertaisuuden ja ihmisten luettavuuden vuoksi XML: n suosio on kasvanut huimasti sovelluskehittäjien keskuudessa ja siitä on tullut välttämätön osa yritysarkkitehtuuria.

Vaikka XML: n käyttötapojen lukumäärää on vaikea selvittää, yksi asia voi olla varma: XML on jäsennettävä ennen kuin mitään muuta voidaan tehdä. Itse asiassa oikean jäsentimen valinta on usein yksi ensimmäisistä päätöksistä, joihin yrityksen kehittäjien on puututtava projekteissaan. Ja uudestaan ​​ja uudestaan, tämä päätös tulee kahteen suosittuun XML-käsittelymalliin: Document Object Model (DOM) ja Simple API for XML (SAX).

Ensi silmäyksellä DOM: n ja SAX: n vastaavat vahvuudet ja heikkoudet näyttävät täydentävän toisiaan: DOM rakentaa muistissa olevia objektikaavioita; SAX on tapahtumapohjainen eikä tallenna mitään muistiin. Joten jos asiakirjan koko on pieni ja tiedonsiirtomalli monimutkainen, DOM on oikea tapa edetä; muuten käytä SAX: ia.

Totuus ei kuitenkaan ole koskaan niin yksinkertaista. Useimmiten kehittäjät eivät halua käyttää SAX: ta sen monimutkaisuuden vuoksi, mutta silti, koska muuta elinkelpoista valintaa ei ole käytettävissä. Muussa tapauksessa, jos XML-tiedostokoko on vain hieman suurempi kuin muutama sataa kilotavua, DOM: n muistista ja suorituskyvystä tulee vakava este sovelluskehittäjille, mikä estää heitä saavuttamasta projektinsa vähimmäistehokkuustavoitteita.

Mutta onko SAX todella paljon parempi? SAX: n mainostama jäsennysteho - tyypillisesti useita kertoja nopeammin kuin DOM - on itse asiassa usein pettää. Osoittautuu, että SAX-jäsentämisen hankala, vain eteenpäin suuntautuva luonne ei vain vaadi ylimääräisiä toteutusponnisteluja, vaan myös suoritusrangaistuksia, kun asiakirjan rakenne muuttuu vain hieman monimutkaiseksi. Jos kehittäjät päättävät olla skannaamatta asiakirjaa useita kertoja, heidän on puskuroitava asiakirja tai rakennettava mukautettuja objektimalleja.

Kummassakin tapauksessa suorituskyky kärsii, kuten Apache Axis kuvaa. Usein kysytyt kysymykset -sivulla Axis väittää käyttävänsä SAX: ää sisäisesti tehokkaamman toteutuksen luomiseen, mutta silti se rakentaa oman objektimallinsa, joka on melko DOM-tyyppinen, mikä johtaa merkityksettömiin suorituskyvyn parannuksiin edeltäjäänsä (Apache SOAP) verrattuna. Lisäksi SAX ei toimi hyvin XPathin kanssa, eikä yleensä voi ohjata XSLT (Extensible Stylesheet Language Transformation) -prosessointia. Joten SAX-jäsentely hajauttaa XML-käsittelyn todelliset ongelmat.

Etsitään helppokäyttöisempää vaihtoehtoa SAX: lle, kasvava määrä kehittäjiä on kääntynyt StAX: n (Streaming API for XML) puoleen. Verrattuna SAX: iin StAX-jäsentäjät vetävät tunnuksia XML-tiedostoista sen sijaan, että käyttäisivät takaisinsoittoja. Vaikka ne parantavat huomattavasti käytettävyyttä, peruskysymykset jatkuvat - StAX: n vain eteenpäin suuntautuva jäsentelytyyli vaatii silti työlästä käyttöönottoa ja sen mukana piilotettuja suorituskykykuluja.

Alarivi: Jotta mikä tahansa XML-käsittelymalli olisi laajasti hyödyllinen, sen on esitettävä XML: n hierarkkinen rakenne eikä vähempää. Syynä on se, että XML on suunniteltu siirtämään monimutkaisia ​​tietoja verkon yli, ja rakenteellisten tietojen välittäminen on luontainen osa XML: n toimintaa.

VTD-XML muuttaa peliä

Oletetaan, että meidän on aloitettava XML-käsittely alusta alkaen voidaksemme ratkaista edellä mainitut DOM: n ja SAX: n ongelmat. Uudella mallilla pitäisi olla todennäköisesti seuraavat ominaisuudet:

  • Satunnainen käyttömahdollisuus: Käsittelymallin pitäisi antaa kehittäjän liikkua jonkinlaisessa hierarkkisessa rakenteessa joko manuaalisesti tai paremmalla tavalla XPathia käyttämällä.
  • Korkea suorituskyky: Suorituskyvyn tulisi olla huomattavasti parempi kuin DOM ja SAX. Ja suorituskyvyn tulisi olla "rehellistä", eli mittauksen on sisällettävä hierarkkisen rakenteen rakentamiseen käytetty aika.
  • Vähäinen muistin käyttö: Jotta käsittelymalli olisi sovellettavissa monenlaisiin skenaarioihin ja tiedostokokoihin, sen on esitettävä XML: n koko rakenne ja vähimmäismäärä muistia.

Suunniteltu täyttämään nämä tavoitteet, VTD-XML on seuraavan sukupolven avoimen lähdekoodin XML-käsittelymalli, joka tuo perustavanlaatuisia ja yleisiä parannuksia DOM: iin ja SAX: iin. Yksi keskeinen VTD-XML-optimointi on ei-ekstraktiivinen tokenisaatio. Sisäisesti VTD-XML säilyttää muistissa vahingoittumattoman ja koodaamattoman XML-sanoman ja edustaa tokeneja yksinomaan binäärikoodausmäärityksen, jota kutsutaan Virtaali Token D.kuvaaja. VTD-tietue on 64-bittinen kokonaisluku, joka koodaa tunnuksen pituuden, aloitussiirron, tyypin ja tunnuksen sisäkkäisyyden XML: ssä.

Tässä on vähän VTD-XML: n historiaa, jos olet kiinnostunut: Peruskonsepti on suunniteltu tapa siirtää XML-käsittely omistetulle laitteistolle FPGA: n tai ASIC: n muodossa, jotta verkkokytkimet ja reitittimet voivat käsitellä XML: ää sisältöä erittäin suurilla nopeuksilla. Myöhemmin VTD-XML-projektitiimi päätti avata avoimen lähdekoodin VTD-XML: n, ja alkuperäinen julkaisu - version 0.5 ja Java-käyttöönotto - tapahtui toukokuussa 2004. Tämän julkaisun jälkeen VTD-XML on käynyt läpi useita parannuksia ja kypsynyt huomattavasti. Versiossa 0.8 julkaistiin VTD-XML: n C-versio yhdessä Java-version kanssa. Sisäänrakennettu XPath-tuki otettiin käyttöön versiossa 1.0 ja julkaistiin lokakuussa 2005. Viimeisimmässä versiossa 1.5 on uudelleenkirjoitettu jäsennysmoottori, joka on modulaarisempi ja tehokkaampi.

Tässä julkaisussa on myös ominaisuus, jota kutsutaan puskurin uudelleenkäytöksi. Perusajatuksena on, että kun verkkoyhteyden takana istuvan XML-sovelluksen on käsiteltävä toistuvasti monia saapuvia XML-asiakirjoja, sovellus voi tosiasiallisesti käyttää uudelleen ensimmäisen käsittelyajon aikana varattuja muistipuskureita. Toisin sanoen allokoi puskurit kerran ja käytä niitä monta kertaa. Erityisesti VTD-XML: lle tämä ominaisuus mahdollistaa sekä objektien luomisen että roskien keräyskustannusten (50-80 prosenttia DOM: n ja SAX: n yleiskustannuksista) täydellisen poistamisen XML-käsittelystä. Projektisivusto sisältää uusimmat ohjelmistolataukset ja perusteellisen teknisen kuvauksen VTD-XML: stä.

Nopea esimerkki

Jotta saat tuntuman VTD-XML: n ohjelmointityylistä, tässä artikkelissa verrataan ensin sekä VTD-XML- että DOM-koodia jäsentämään ja navigoimaan yksinkertaista XML-tiedostoa nimeltä test.xml, jonka tekstisisältö näkyy alla:

  Ruohonleikkuri 1148,95 

VTD-XML-versio näyttää tältä:

tuo com.ximpleware. *; tuo com.ximpleware.parser. *; tuo java.io. *;

public class use_vtd {public static void main (String [] args) {kokeile {File f = uusi tiedosto ("test.xml"); FileInputStream fis = uusi FileInputStream (f); tavu [] ba = uusi tavu [(int) f.pituus ()]; fis.read (ba); VTDGen vg = uusi VTDGen (); vg.setDoc (ba); vg.parse (väärä); VTDNav vn = vg.getNav (); if (vn.matchElement ("purchaseOrder")) {System.out.println ("orderDate ==>" + vn.toString (vn.getAttrVal ("orderDate"))); if (vn.toElement (VTDNav.FIRST_CHILD, "kohde")) {if (vn.toElement (VTDNav.FIRST_CHILD)) {tee {System.out.print (vn.toString (vn.getCurrentIndex ())); System.out.print ("==>");

System.out.println (vn.toString (vn.getText ())); } while (vn.toElement (VTDNav.NEXT_SIBLING)); }}}} catch (Poikkeus e) {System.out.println ("poikkeus tapahtui ==>" + e); }}}

Saman sovelluksen DOM-versio on esitetty alla:

tuo java.io. *; tuo org.w3c.dom. *; tuonti org.w3c. *; tuo javax.xml.parsers. *; tuo javax.xml.parsers.DocumentBuilder; tuo javax.xml.parsers.DocumentBuilderFactory; tuo javax.xml.parsers.FactoryConfigurationError; tuo javax.xml.parsers.ParserConfigurationException; tuo org.w3c.dom. *; tuo org.xml.sax.SAXException;

public class use_dom {public static void main (String [] args) {kokeile {DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance (); DocumentBuilder-jäsennin = factory.newDocumentBuilder (); Asiakirja d = parser.parse ("test.xml"); Elementtijuuri = d.getDocumentElement (); if (root.getNodeName (). CompareTo ("purchaseOrder") == 0) {System.out.println ("orderDate ==>" + root.getAttribute ("orderDate"));

Solmu n = root.getFirstChild (); if (n! = null) {do {if (n.getNodeType () == Solmu.ELEMENT_NODE && n.getNodeName (). vertaile ("kohde") == 0) {Solmu n2 = n.getFirstChild (); if (n2! = null) {do {if (n2.getNodeType () == Solmu.ELEMENT_NODE) ​​{System.out.println (n2.getNodeName () + "==>" + n2.getFirstChild (). getNodeValue ( )); }} while ((n2 = n2.getNextSibling ())! = null); }}} while ((n = n.getNextSibling ())! = null); }}} catch (Poikkeus e) {System.out.println ("poikkeus tapahtui ==>" + e); }}}

Kuten yllä olevista koodiesimerkkeistä käy ilmi, VTD-XML liikkuu XML-hierarkiassa käyttämällä kohdistinpohjaista sovellusliittymää. Sitä vastoin DOM-sovellusliittymä navigoi hierarkiassa pyytämällä objektiviittauksia. Vieraile VTD-XML-projektin verkkosivustolla saadaksesi lisää teknisiä materiaaleja ja koodiesimerkkejä, jotka selittävät VTD-XML: ää perusteellisesti.

Vertailuanalyysi VTD-XML

Seuraavaksi verrataan VTD-XML: n suorituskykyä ja muistin käyttöä joihinkin suosittuihin XML-jäsentimiin. On huomattava, että useimmat artikkelit, jotka sisältävät vertailunumeroita, kuten Dennis Sosnoskin "XML-asiakirjat käynnissä" (JavaWorld, Huhtikuu 2002) ovat peräisin useita vuosia sitten. Siitä lähtien paremmat ja nopeammat laitteistot noudattavat Mooren lakia ja ovat halvempia kuin koskaan. Samaan aikaan XML-jäsentäminen ja Java-virtuaalikone eivät ole pysyneet paikallaan - heillä on tapahtunut parannuksia monilla avainalueilla.

Testaa asetukset

Testialusta on Sony VAIO -kannettava, joka on varustettu Pentium M 1,7 GHz -prosessorilla (2 Mt integroitua L2-välimuistia) ja 512 Mt DDR2-RAM-muistilla. Etuväylän kellotaajuus on 400 MHz. Käyttöjärjestelmä on Windows XP Professional Edition ja Service Pack 2. JVM on versio 1.5.0_06.

Vertailuarvo testaa seuraavien XML-jäsentäjien uusimmat versiot:

  • Xerces DOM 2.7.1, solmun laajennuksella tai ilman sitä
  • Xerces SAX 2.7.1
  • Piccolo SAX 1.04
  • XPP3 1.1.3.4.O
  • VTD-XML 1.5, puskurin uudelleenkäytöllä ja ilman sitä

Valitsin testiin suuren joukon erikokoisia ja monimutkaisia ​​XML-asiakirjoja. Tiedostokoon mukaan testidokumentit on ryhmitelty kolmeen luokkaan. Pienet tiedostot ovat kooltaan alle 10 kt. Keskikokoisten tiedostojen koko on 10 kt - 1 MB. Yli 1 Mt tiedostoja pidetään suurina.

Palvelinta JVM käytettiin kaikissa suorituskyvyn mittauksissa huippusuorituskyvyn saamiseksi. Näissä testeissä vertailuohjelmat etsivät ensin jäsentely- tai navigointirutiineja useita kertoja niin, että JVM suoritti tavukoodin dynaamisen, juuri oikeaan aikaan -optimoinnin, ennen kuin keskiarvoistettiin seuraavien iteraatioiden suorituskyky lopullisina tuloksina. Levyn I / O: n aiheuttamien ajoitusten vaihtelujen vähentämiseksi vertailuohjelmat lukevat kaikki XML-tiedostot muistipuskureihin ennen testiajoja.

merkintä: Kiinnostuneet lukijat voivat ladata vertailuohjelman Resursseista.

Suoritustehtävien vertailu

Tämä osa esittelee XML-jäsentämisen suorituskyvyn sekä viiveellä että läpäisykyvyllä. Huomaa, että vaikka VTD-XML ja DOM ovat suoraan vertailukelpoisia, ei ole oikeudenmukaista verrata VTD-XML: ää SAX: n tai Pullin kanssa, koska ne eivät rakenna mitään hierarkkista rakennetta muistiin. Joten SAX: n ja Pullin suorituskyky toimii vain lisäviitekohtana.

Suorituskyky

Latenssivertailut

Taulukko 1. Pienet tiedostot

Tiedoston nimi / kokoVTD-XML (ms)VTD-XML-puskurin uudelleenkäyttö (ms)SAX (ms)DOM (ms)DOM lykätty (ms)Piccolo (ms)Vedä (ms)
soap2.xml (1727 tavua)0.04460.03460.07820.11220.162250.0920.066
nav_48_0.xml (4608 tavua)0.10540.09280.2660.370.3850.27840.1742
cd_catalog.xml (5035 tavua)0.1180.1080.190.3480.40.20.214
nav_63_0.xml (6848 tavua)0.1490.1350.3540.5130.5570.4840.242
nav_78_0.xml (6920 tavua)0.1530.1420.37040.5880.520.420.29

Taulukko 2. Keskisuuret XML-tiedostot

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