2007/06/14

DOM, SAX, StAX

XML-t parsolni rengeteg féle képpen lehet, a legismertebb módszerek mégis a fent említett apik. A DOM berántja az egész fájlt a merióba és viszonylag kényelmesen lehet utána kutakodni benne. A Sax egy sokkal kevésbé erőforrás igényesebb push parser: a feldolgozó megy végig az elemeken és közben a találta elemeknek megfelelő földolgozó függényeink (startElement, startDocument,...) szájába nyomja bele az adatokat. a StAX ezzel szemben remek pull parser. Szintén kevés erőforrsát eszik (nem tartja a memóriában az egész fájlt), és nem ő dirigál, hanem a programunk. Ha én azt mondom, hogy kérem a következő XML elemet, akkor megy tovább csak a parsolásban.

Hogy melyiket válasszuk, az a szokásos attól függ kérdés. Rövid segítség a döntésben pl. a java tutorialban.

Nálam a konkrét példa ez volt: viszonylag kicsi XML-ek zúdulnak rám eszméletlen sebességgel (JMS). Meg kell keresni mindegyikben két teget (kb. az első negyedben vannak) és az alapján kell megnézni, hogy akarok-e e velük kezdeni valamit. Amivel akarok, az kevesen van, azt már bárhogy feldolgozhatom.

Mivel gyorsnak kell lennni, egyértelmű hogy StAX vagy SAX. A StAX feldolgozását könnyen meg lehet szakítani (mivel én dirigálom, mikor jöjjön a feldolgozás bármikor abbahagyathatom), a SAX feldolgozásból legfeljebb exceptionnal lehet kijönni (ami azért nem egy szépségdíjas megoldás). Legyen tehát StAX. Illetve legyen mind3, és mérjem meg, hogy tényleg annyival gyorsabb-e a SAX/StAX mint a DOM, és hogy a konrét esetben a StAX/SAX sebesség mennyire vethető össze.

Nosza gyorsan összedobtam a kódokat, és rájuk eresztettem 3000 XML fájlt. Az eredmény: DOM ~ 100% sec, SAX ~ 80-90% sec, StAX 50 ~ sec. Érdekes, hogy a nagy szakadén nem a Stax/SAX vs. DOM között van, hanem a a StAX és az öszes többi között.

A történet szépsége az persze, hogy kiderült, hogy 3000 fájl feldolgozása is max 2-4 sec, és mivel adatbázisba is kell írni belőlük az adatokat, ezért valószínű tök mindegy mit használok, mert nem a parzolásnál fogok elvérezni. (Ráadásul háttér procesz, ahol 1-2 mp nem számít).

2 megjegyzés:

Stef írta...

Szerintem nem szabad megfelejtkezni arról, hogy ha adatbázis hangolásra kerül sor a teljesítmény problémák miatt, akkor nem lesz mindegy, hogy melyik megoldás lett megvalósítva egy magasabb rétegben :-)

Márpedig minden teljesítmény problémát lentről felfele próbálnak megoldani: hardwer -> OS -> adatbázis -> alkalmazás szerver -> alkalmazás.
A tapasztalatom az, hogy egy bevezetett rendszernél legutóljára, és csak a végső esetben nyúlnak az alkalmazáshoz, mert az a legköltségesebb és legérzékenyebb terület...

Uff... :-)

anon_anon írta...

you might also want to look at vtd-xml, the latest and most advanced XML processing API available today


http://vtd-xml.sf.net