2009-06-06 5 views
12

Ich habe nicht viele Möglichkeiten gefunden, um die Leistung einer Java-Anwendung zu erhöhen, die intensive XML-Verarbeitung anders als die Verwendung von Hardware wie Tarari oder Datapower. Kennt jemand Open-Source-Möglichkeiten, um das XML-Parsing zu beschleunigen?Gibt es schnellere XML-Parser in Java als Xalan

+3

Sie erhalten bessere Antworten, wenn Sie näher erläutern, welche Art von XML-Verarbeitung Sie durchführen. Sind Sie durch eine bestimmte API (DOM) eingeschränkt? Wie viel von dem XML müssen Sie im Speicher speichern? Wie viele verschiedene Schemas müssen Sie unterstützen? Können Sie vertrauen, dass XML gültig ist? .. – ykaganovich

+1

Verwandte Frage: 'Schnellster XML-Parser für kleine, einfache Dokumente in Java', http://stackoverflow.com/questions/530064/fastest-xml-parser-for-small-simple -documents-in-java – Jonik

+0

Schauen Sie sich dieses 2013 Papier an, es macht viel Benchmarking http://sdiwc.us/digitlib/journal_paper.php?paper=00000582.pdf –

Antwort

8

Werfen Sie einen Blick auf Stax (Streaming) Parser. Siehe the sun reference manual. Eine der Implementierungen ist die woodstox project.

+1

http://www.xml.com/pub/a /2007/05/09/xml-parser-benchmarks-part-1.html hat einen guten Überblick über XML-Parser-Geschwindigkeiten. Woodstox sieht ziemlich gut aus. –

+1

STAX ist der Weg zu gehen und Woodstox ist super schnell. – casey

+0

Stax ist viel langsamer als VTD-xml –

0

Piccolo Ansprüche zu sein pretty fast. Ich kann nicht sagen, dass ich es selbst benutzt habe. Sie könnten auch versuchen, JDOM. Wie immer, Benchmark mit repräsentativen Daten Ihrer real laden.

Es hängt teilweise davon ab, was Sie versuchen zu tun. Müssen Sie das gesamte Dokument in den Speicher ziehen, oder können Sie in einem streaming manner arbeiten? Verschiedene Ansätze haben unterschiedliche Kompromisse und sind besser für verschiedene Situationen.

+2

Piccolo scheint Geschwindigkeit für die Richtigkeit zu handeln, die möglicherweise oder vielleicht nicht was du willst. (http://cafeconleche.org/SAXTest/paper.html#S4.2.4) –

+1

Bei aller Fairness ist es eher unwahrscheinlich, dass Abweichungen sich auf Fälle auswirken, in denen Leistung eine Rolle spielt (die in der Regel einfache (r) Anwendungsfälle sind). SAXTest neigt dazu, sich auf komplizierte Fälle von DTD-Nutzung und Korrektheit zu konzentrieren. Aber während Piccolo 2004 vielleicht schneller gewesen ist, wurde es nicht viel entwickelt, und andere haben eingeholt, und einige übertreffen es (Xerces ist so schnell, Woodstox und besonders Aalto schneller) – StaxMan

0

Abhängig von der Komplexität Ihrer XML-Nachrichten können Sie einen benutzerdefinierten Parser 10x schneller finden (obwohl mehr Arbeit zum Schreiben). Wenn Leistung jedoch kritisch ist, würde ich keinen generischen Parser vorschlagen. (Auch würde ich vorschlagen, nicht unter Verwendung von XML als nicht für Leistung ausgelegt, aber das ist eine andere Geschichte, ..;)

+3

Schreiben von benutzerdefiniertem XML Parser ist zeitaufwendig und fehleranfällig. Es ist nicht einfach, XML richtig zu machen, vor allem, wenn Sie XML-Dokumente aus der freien Wildbahn analysieren wollen. (http://cafeconleche.org/SAXTest/) –

+0

Dies ist alles wahr, weshalb es die meiste Zeit keine gute Idee ist. Wenn die Geschwindigkeit jedoch kritisch ist, können Sie eine 10-fache Verbesserung erzielen. –

+0

Huh? Hast du das jemals wirklich versucht? Das Schreiben eines benutzerdefinierten Parsers, der ANY schneller ist, ist nicht trivial. Schnellste vorhandene Parser analysieren mit 30-60 MBps Rate; nicht viel langsamer als Sie einfachen UTF-8-Text dekodieren können. 10x, auf keinen Fall, absolut nicht. Fühlen Sie sich frei, versuchen Sie, einige Zahlen zu bekommen. :-) – StaxMan

0

prüfen Javolution auch

+3

Ich stimme nicht zu. Javolts XML- "Parser" überprüft keine Probleme mit XML (doppelte Attribute), behandelt keine Namespaces, implementiert keine Standard-API. Und ist nicht noch schneller. – StaxMan

+1

@StaxMan auf der hellen Seite erstellt es nicht so viel Müll beim Parsen, und manchmal in der Lage, fehlerhafte XML zu lesen ist ein Bonus –

+1

Wert der ultraniedrigen Müllproduktion ist eine offene Frage auf den meisten Plattformen; und die meisten Streaming-Parser sind ohnehin recht sparsam mit der Objekterzeugung. Wenn Sie es nützlich finden, gut für Sie. Ich muss es nur noch in diesem Zusammenhang sehen. Was ungültiges XML betrifft, bin ich der Meinung, dass es besser ist, nicht damit umgehen zu können und Druck auf Produzenten von kaputten Dingen auszuüben. Aber YMMV, jeder für sich. – StaxMan

3

VTD-XML sehr schnell ist.

Es hat eine DOM-ähnliche API und sogar XPath-Abfragen.

Verwandte Themen