3 paveikslas. Dideli XML failai. Norėdami pamatyti pilno dydžio vaizdą, spustelėkite miniatiūrą.
Praėjus aštuoneriems metams nuo savo įkūrimo, XML jau tapo atviru, pusiau struktūrizuotu duomenų formatu, kuriame saugomi duomenys ir keičiamasi duomenimis internete. Dėl paprastumo ir suprantamumo žmonėms XML pastebėjo populiarumą tarp programų kūrėjų ir tapo nepakeičiama įmonės architektūros dalimi.
Nors sunku išvardyti XML naudojimo būdų skaičių, galime būti tikri dėl vieno dalyko: prieš ką nors darant, XML turi būti analizuojamas. Tiesą sakant, tinkamo analizatoriaus pasirinkimas dažnai yra vienas iš pirmųjų sprendimų, kuriuos įmonės kūrėjai turi įgyvendinti savo projektuose. Ir vėl ir vėl šis sprendimas priklauso nuo dviejų populiarių XML apdorojimo modelių: „Document Object Model“ (DOM) ir „Simple API for XML“ (SAX).
Iš pirmo žvilgsnio atitinkamos DOM ir SAX stipriosios ir silpnosios pusės viena kitą papildo: DOM kuria atminties objektų grafikus; „SAX“ yra pagrįstas įvykiais ir nieko neišsaugo atmintyje. Taigi, jei dokumento dydis yra mažas ir prieigos prie duomenų modelis sudėtingas, DOM yra kelias; priešingu atveju naudokite SAX.
Tačiau tiesa niekada nėra tokia supaprastinta. Dažniausiai kūrėjai nenori naudoti SAX dėl savo sudėtingumo, tačiau vis tiek naudojasi, nes nėra kito tinkamo pasirinkimo. Priešingu atveju, jei XML failo dydis yra tik šiek tiek didesnis nei keli šimtai kilobaitų, DOM atminties pridėtinė vertė ir našumas tampa sudėtinga kliūtimi programų kūrėjams, neleidžiantiems pasiekti minimalių savo projekto rezultatų.
Bet ar tikrai SAX yra daug geresnis? „SAX“ reklamuojamas analizavimo našumas - paprastai kelis kartus greitesnis nei DOM - iš tikrųjų dažnai klaidina. Pasirodo, kad nepatogus, tik į priekį nukreiptas SAX analizės pobūdis reikalauja ne tik papildomų įgyvendinimo pastangų, bet ir už našumą, kai dokumento struktūra tampa tik šiek tiek sudėtinga. Jei kūrėjai nuspręs nenuskaityti dokumento kelis kartus, jie turės sukonfigūruoti dokumentą arba sukurti pritaikytus objektų modelius.
Bet kokiu atveju našumas kenčia, kaip pavyzdį rodo „Apache Axis“. DUK puslapyje „Axis“ teigia, kad sukuria efektyvesnį diegimą, naudodamas SAX, tačiau vis tiek kuria savo objekto modelį, kuris yra gana panašus į DOM, o tai lemia nežymius našumo patobulinimus, palyginti su ankstesniu („Apache SOAP“). Be to, SAX neveikia gerai su XPath ir apskritai negali valdyti XSLT (Extensible Stylesheet Language Transformation) apdorojimo. Taigi, „SAX“ analizuojant, yra tikrosios XML apdorojimo problemos.
Siekdami lengviau naudoti SAX alternatyvą, vis daugiau kūrėjų kreipėsi į „StAX“ („Streaming API for XML“). Palyginti su SAX, „StAX“ analizatoriai iš XML failų traukia žetonus, užuot naudoję skambučių atgal. Nors jie pastebimai pagerina patogumą, pagrindinės problemos išlieka - „StAX“ tik į priekį analizavimo stilius vis tiek reikalauja nuobodžių diegimo pastangų ir kartu paslėptų našumo išlaidų.
Esmė: Kad bet kuris XML apdorojimo modelis būtų iš esmės naudingas, jis turi pateikti XML hierarchinę struktūrą ir ne mažiau. Priežastis yra ta, kad XML yra skirtas sudėtingiems duomenims perkelti internete, o struktūrinės informacijos perdavimas yra neatskiriama XML veiklos dalis.
VTD-XML keičia žaidimą
Tarkime, kad turėtume pradėti XML apdorojimą nuo nulio, kad išspręstume minėtas problemas su DOM ir SAX. Naujasis modelis tikriausiai turėtų turėti šias savybes:
- Galima atsitiktinė prieiga: Apdorojimo modelis turėtų leisti kūrėjui naršyti tam tikroje hierarchinėje struktūroje rankiniu būdu arba, geriau, naudojant XPath.
- Didelis našumas: Našumas turėtų būti žymiai geresnis nei DOM ir SAX. Našumas turėtų būti „sąžiningas“, tai reiškia, kad vertinimas turi apimti laiką, praleistą hierarchinei struktūrai kurti.
- Mažas atminties naudojimas: Kad apdorojimo modelis būtų pritaikytas įvairiems scenarijams ir failų dydžiams, jis turi pateikti visą XML struktūrą su minimaliu atminties kiekiu.
Sukurtas šiems tikslams pasiekti, VTD-XML yra naujos kartos atvirojo kodo XML apdorojimo modelis, suteikiantis esminių ir visapusiškų patobulinimų, palyginti su DOM ir SAX. Vienas pagrindinių VTD-XML optimizavimo būdų yra neekstrahuojantis žymėjimas. VTD-XML atmintyje išlaiko nepažeistą ir neužkoduotą XML pranešimą ir žymi žetonus, pagrįstus tik dvejetainio kodavimo specifikacija, vadinama Viracionalus Tgerai Daprašytojas. VTD įrašas yra 64 bitų sveikas skaičius, kuris XML koduoja žetono ilgį, pradžios poslinkį, tipą ir žetono įdėjimo gylį.
Čia yra šiek tiek VTD-XML istorijos tuo atveju, jei jus domina: Pagrindinė koncepcija buvo sukurta kaip būdas perkelti XML apdorojimą tam skirtoje aparatinėje įrangoje, FPGA arba ASIC pavidalu, kad tinklo jungikliai ir maršrutizatoriai galėtų apdoroti XML turinį labai dideliu greičiu. Vėliau VTD-XML projekto komanda nusprendė atidaryti VTD-XML, o 2004 m. Gegužę įvyko pirminis „Java“ versijos 0.5 leidimas. Nuo to laiko VTD-XML buvo patobulintas ir subrendo. gerokai. Versijoje 0.8 buvo išleista VTD-XML C versija kartu su „Java“ versija. Integruotas „XPath“ palaikymas buvo pristatytas 1.0 versijoje ir išleistas 2005 m. Spalio mėn. Naujausiame leidime, 1.5 versijoje, yra perrašytas analizavimo variklis, kuris yra modulinis ir našesnis.
Šiame leidime taip pat pristatoma funkcija, vadinama buferio pakartotiniu naudojimu. Pagrindinė mintis yra ta, kad kai už tinklo ryšio sėdinti XML programa turi pakartotinai apdoroti daugybę gaunamų XML dokumentų, programa iš tikrųjų gali pakartotinai naudoti atminties buferius, paskirtus per pirmąjį apdorojimo procesą. Kitaip tariant, vieną kartą paskirstykite buferius ir naudokite juos daug, daug kartų. Ši funkcija, būdinga VTD-XML, leidžia visiškai pašalinti objektų kūrimo ir šiukšlių surinkimo išlaidas (50–80 proc. Pridėtinių išlaidų DOM ir SAX) iš XML apdorojimo. Projekto svetainėje pateikiami naujausi programinės įrangos atsisiuntimai ir išsamus VTD-XML techninis aprašymas.
Trumpas pavyzdys
Norint pajusti VTD-XML programavimo stilių, šiame straipsnyje pirmiausia lyginamas kodas naudojant tiek VTD-XML, tiek DOM, norint išanalizuoti ir naršyti paprastą XML failą, pavadintą test.xml, kurio teksto turinys rodomas žemiau:
Vejapjovė 1 148,95 VTD-XML versija atrodo taip:
importuoti com.ximpleware. *; importuoti com.ximpleware.parser. *; importuoti java.io. *;
public class use_vtd {public static void main (String [] args) {try {File f = new File ("test.xml"); FileInputStream fis = nauja FileInputStream (f); baitas [] ba = naujas baitas [(int) f.length ()]; fis.read (ba); VTDGen vg = naujas VTDGen (); vg.setDoc (ba); vg.parse (klaidinga); VTDNav vn = vg.getNav (); if (vn.matchElement ("purchaseOrder")) {System.out.println ("orderDate ==>" + vn.toString (vn.getAttrVal ("orderDate"))); if (vn.toElement (VTDNav.FIRST_CHILD, "elementas")) {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)); }}}} sugavimas (e išimtis) {System.out.println ("įvyko išimtis ==>" + e); }}}
Toliau pateikiama tos pačios programos DOM versija:
importuoti java.io. *; importuoti org.w3c.dom. *; importuoti org.w3c. *; importuoti javax.xml.parsers. *; importuoti javax.xml.parsers.DocumentBuilder; importuoti javax.xml.parsers.DocumentBuilderFactory; importuoti javax.xml.parsers.FactoryConfigurationError; importuoti javax.xml.parsers.ParserConfigurationException; importuoti org.w3c.dom. *; importuoti org.xml.sax.SAXException;
public class use_dom {public static void main (String [] args) {try {DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance (); „DocumentBuilder“ analizatorius = factory.newDocumentBuilder (); Dokumentas d = parser.parse ("test.xml"); Elemento šaknis = d.getDocumentElement (); if (root.getNodeName (). palygintiTo ("purchaseOrder") == 0) {System.out.println ("orderDate ==>" + root.getAttribute ("orderDate"));
Mazgas n = root.getFirstChild (); if (n! = null) {do {if (n.getNodeType () == Mazgas.ELEMENT_NODE && n.getNodeName (). CompareTo ("elementas" = = 0) {Mazgas n2 = n.getFirstChild (); if (n2! = null) {do {if (n2.getNodeType () == Mazgas.ELEMENT_NODE) {System.out.println (n2.getNodeName () + "==>" + n2.getFirstChild (). getNodeValue ( )); }} while ((n2 = n2.getNextSibling ())! = null); }}} while ((n = n.getNextSibling ())! = null); }}} sugavimas (e išimtis) {System.out.println ("įvyko išimtis ==>" + e); }}}
Kaip parodyta aukščiau pateiktuose kodų pavyzdžiuose, VTD-XML naršo XML hierarchijoje naudodama žymekliu pagrįstą API. Priešingai, DOM API naršo hierarchiją prašydama objektų nuorodų. Apsilankykite VTD-XML projekto svetainėje, kur rasite daugiau techninės medžiagos ir kodų pavyzdžių, kurie labai išsamiai paaiškina VTD-XML.
Lyginamoji VTD-XML analizė
Tada palyginkime VTD-XML našumą ir atminties naudojimą su kai kuriais populiariais XML analizatoriais. Pažymėtina, kad daugumoje straipsnių, kuriuose yra etalonų skaičiai, pvz., Denniso Sosnoskio „XML dokumentai bėgant“ („JavaWorld“, Balandžio mėn. Nuo tada geresnė ir greitesnė aparatūra laikosi Moore'o dėsnio ir tampa pigesnė nei bet kada. Tuo pačiu metu XML analizavimas ir „Java“ virtualioji mašina nestovi vietoje - jie patobulėjo daugelyje pagrindinių sričių.
Bandymo sąranka
Bandomoji platforma yra „Sony VAIO“ nešiojamas kompiuteris su „Pentium M“ 1,7 GHz procesoriumi (2 MB integruota L2 talpykla) ir 512 MB DDR2 RAM. Priekinės magistralės dažnis yra 400 MHz. OS yra „Windows XP Professional Edition“ su 2 pakeitimų paketu. JVM yra 1.5.0_06 versija.
Palyginamasis testuoja naujausias šių XML analizatorių versijas:
- „Xerces DOM 2.7.1“, su atidėtu mazgo išplėtimu ir be jo
- „Xerces SAX“ 2.7.1
- „Piccolo SAX 1.04“
- XPP3 1.1.3.4.O
- VTD-XML 1.5 su buferio pakartotiniu naudojimu ir be jo
Testui pasirinkau didelę įvairaus dydžio ir struktūros sudėtingumo XML dokumentų kolekciją. Priklausomai nuo bylos dydžio, bandomieji dokumentai yra sugrupuoti į tris kategorijas. Mažų failų dydis yra mažesnis nei 10 KB. Vidutinio dydžio failai yra nuo 10 KB iki 1 MB. Didesni nei 1 MB failai laikomi dideliais.
Serverio JVM buvo naudojamas visiems našumo matavimams, norint gauti didžiausią našumą. Atliekant šiuos bandymus, etalono programos pirmą kartą daug kartų perskaičiavo analizės ar naršymo tvarką, kad JVM atliktų dinamišką, tik laiku optimizuotą baito kodą, prieš paskaičiuodamas vėlesnių pakartojimų našumą kaip galutinius rezultatus. Norėdami sumažinti laiko skirtumus dėl disko įvesties / išvesties, etaloninės programos prieš bandydami paleisti visus XML failus nuskaito į atminties buferius.
Pastaba: Suinteresuoti skaitytojai gali atsisiųsti etalonų programą iš išteklių.
Analizuojant pralaidumo palyginimus
Šiame skyriuje pateikiamas XML analizės našumas tiek latentiniu, tiek pralaidumu. Atkreipkite dėmesį, kad nors VTD-XML ir DOM yra tiesiogiai palyginami, nėra teisinga lyginti VTD-XML su „SAX“ ar „Pull“, nes jie nesudaro jokios hierarchinės struktūros atmintyje. Taigi „SAX“ ir „Pull“ veikimas yra tik papildomas atskaitos taškas.
Pralaidumas
Latentiniai palyginimai
1 lentelė. Maži failai
|
2 lentelė. Vidutiniai XML failai
