2009-06-06 10 views
12

Non ho trovato molti modi per aumentare le prestazioni di un'applicazione Java che esegue un'elaborazione XML intensiva se non per sfruttare hardware come Tarari o Datapower. Qualcuno sa di metodi open source per accelerare l'analisi XML?Esistono parser XML più veloci in Java rispetto a Xalan/Xerces

+3

Otterrete risposte migliori se elaborate il tipo di elaborazione XML che state facendo. Sei vincolato da una specifica API (DOM)? Quanto dell'XML hai bisogno di archiviare in memoria? Quanti schemi diversi hai bisogno di supportare? Puoi fidarti del fatto che XML sia valido? .. – ykaganovich

+1

Domanda correlata: "Il parser XML più veloce per documenti piccoli e semplici in Java", http://stackoverflow.com/questions/530064/fastest-xml-parser-for-small-simple -documents-in-java – Jonik

+0

Dai un'occhiata a questo documento del 2013 fa molto benchmarking http://sdiwc.us/digitlib/journal_paper.php?paper=00000582.pdf –

risposta

8

Dai un'occhiata ai parser Stax (streaming). Vedi the sun reference manual. Una delle implementazioni è woodstox project.

+1

http://www.xml.com/pub/a /2007/05/09/xml-parser-benchmarks-part-1.html ha una buona panoramica delle velocità del parser XML. Woodstox sembra piuttosto buono. –

+1

STAX è la strada da percorrere e Woodstox è velocissimo. – casey

+0

Stax è molto più lento di VTD-xml –

0

Piccolo reclami da pretty fast. Non posso dire di averlo usato io stesso però. Si potrebbe anche provare JDOM. Come sempre, benchmark con i dati rappresentativi del tuo carico reale.

In parte dipende da cosa si sta tentando di fare. È necessario inserire l'intero documento in memoria o operare in un streaming manner? Approcci diversi hanno diversi compromessi e sono migliori per le diverse situazioni.

+2

Piccolo sembra scambiare velocità per correttezza, che può o potrebbe non essere quello che vuoi. (Http://cafeconleche.org/SAXTest/paper.html#S4.2.4) –

+1

In tutta onestà, è improbabile che le deviazioni influenzino i casi in cui le prestazioni sono importanti (che tendono ad essere semplici (r) casi d'uso) - SAXTest tende a concentrarsi su casi complicati di utilizzo e correttezza della DTD. D'altra parte, mentre Piccolo potrebbe essere stato più veloce nel 2004, non è stato sviluppato molto, e altri hanno raggiunto e alcuni lo superano (Xerces è veloce, Woodstox e soprattutto Aalto più veloce) – StaxMan

0

A seconda della complessità dei messaggi XML, è possibile che un parser personalizzato sia 10 volte più veloce (anche se più lavoro da scrivere) Tuttavia, se le prestazioni sono critiche, non suggerirei di utilizzare un parser generico. (Anche io non suggerirei di usare XML come il suo non è progettata per le prestazioni, ma questa è un'altra storia, ..;)

+3

Scrittura XML personalizzato parser richiede molto tempo ed è soggetto a errori. Ottenere il diritto XML non è facile, soprattutto se si desidera analizzare documenti XML dal loro ambiente naturale. (http://cafeconleche.org/SAXTest/) –

+0

Questo è tutto vero, motivo per cui non è una buona idea per la maggior parte del tempo. Tuttavia, se la velocità è critica, puoi ottenere un miglioramento di 10 volte. –

+0

Eh? Hai mai provato a farlo? Scrivere un parser personalizzato che sia ANY più veloce non è banale. I parser esistenti più veloci vengono analizzati con una frequenza di 30-60 MBps; non molto più lentamente di quanto tu possa decodificare il semplice testo UTF-8. 10x, assolutamente no, assolutamente no. Sentiti libero di provare, prendi dei numeri. :-) – StaxMan

0

check Javolution così

+3

Non sono d'accordo. Il "parser" XML di Javolution non verifica NESSUN problema con xml (attributi duplicati), non gestisce gli spazi dei nomi, non implementa alcuna API standard. E non è nemmeno più veloce. – StaxMan

+1

@StaxMan sul lato positivo non crea troppa garbage durante l'analisi, e talvolta è in grado di leggere XML malformato è un bonus –

+1

Il valore della produzione di immondizia ultra-bassa è una domanda aperta sulla maggior parte delle piattaforme; e la maggior parte dei parser di streaming sono comunque abbastanza frugali con la produzione di oggetti. Se lo trovi utile, fa bene a te. Devo ancora vederlo importare in questo contesto. Per quanto riguarda l'XML non valido, sono dell'opinione che sia meglio non essere in grado di gestirlo e applicare una contropressione ai produttori di cose rotte. Ma YMMV, ognuno per conto proprio. – StaxMan

3

VTD-XML è molto veloce.

Ha un'API tipo DOM e anche query XPath.