Endlich mal eine schnelle Xml-Komponente gesucht oder selber tippern?

[hoika]

Hallo,
ein schöner provokanter Titel ;)

ich habe diverse Xml-Dateien (20-50 MB gross).
Der Aufbau ist jeweils pro Datei fest vorgegeben, jeder Knoten ist in einer separaten Zeile (#13#10).

Bei der Nutzung diverser Xml-Komponenten (JEDI NativeXml, MS-XML, TXMLDocument) habe ich immer das Problem,
dass diese zeichenweise durch den ByteStream der Datei durchlaufen und dabei ihre internen Strukturen aufbauen.

Das passt ja auch ganz gut, wenn die Struktur unbekannt ist, aber ist ziemlich langsam.

Bsp.
Eine Datei mit einer sehr einfachen Xml-Struktur dauert aufgrund der Anzahl der Elemente (~50.000) sehr lange.
Baue ich das per StringList nach (ich kenne ja die einfache Struktur der Datei), dauert es statt der 30 Sekunden nur 0,5 Sekunden zum Laden der Daten.
Wie gesagt: Ich kenne die einfache Struktur.

Ich könnte jetzt für eine paar der Dateien eigene Lade-Implementationen bauen,
oder es gibt eine schnellere Implementation für Xml-Dateien?


Als Grundübel habe ich die lange Parser-Zeit und das Einsortieren in interne Strukturen erkannt (Quellcode hatte ich mir bei dem JEDI's angesehen).

Schön wäre eine On-the-fly-Implementierung, die bei jedem Knoten alle Parent-Knoten mitliefert,
und wo ich dann gezielt sagen könnte -> "Nehme ich und packe es in meine eigenen Strukturen".

Kennt jemand so eine Komponente?

[blawen]

Ich pers. nutze die Delphi eigene Komponente (TXMLDocument) und bin damit zufrieden.
Allerdings habe ich keine Erfahrung, mit so grossen Dateien.

[hoika]

Hallo,
Danke, habe das oben gleich mal mit eingefügt ;)
TXMLDocument benutzt ja idR MS-XML.

[hoika]

Hallo,
was ich vorhin mit On-The-Fly meinte, war ein SAX-Parser, siehe auch hier etwa in der Mitte

https://forums.embarcadero.com/messa...ssageID=657749

[sh17]

Also in diesem Fall sollte ein SAX-Parser genommen werden.

Und für XML nutze ich

http://www.kluug.net/oxml.php

Sehr flott

[hoika]

Danke.
Ich schau mir den mal an.

[jaenicke]

Wir benutzen auch Oxml, wodurch die Ladezeiten nur noch grob ein Zehntel so lang sind im Vergleich zum internen Parser von Delphi.

[hoika]

Hallo,
der interne Parser ist ja afaik MS-Xml.

Klingt also erst mal gar nicht schlecht.

[dummzeuch]

MSXML als SAX-Parser ist nach meiner Erfahrung da am schnellsten. (Und ich habe mehr Erfahrung mit XML-Dateien einlesen als mir lieb ist ...)

Nachteil von MSXML ist allerdings, dass das Fehlerhandling eine Katastrophe ist (passenderweise ist die häufigste Fehlermeldung "Catastrophic Failure" ;-) ).

Nur so als Beispiel, wie spaßig das sein kann:

https://stackoverflow.com/questions/...ader-in-delphi

[hoika]

Hallo,
spaßig ist aber anders.

;)

Vielleicht schreibe ich mir doch was eigenes ...

[jobo]

Oder Du schaust Dir mal an, wie man es mit SQL abfragt. Einige können das und sind dabei auch nicht lahm:
Oracle
MS SQL
Postgres
..?

Das böte sich jedenfalls an, wenn solche Systeme sowieso "in der Nähe" sind.

[Frickler]

Wenns nur ums Lesen geht: http://www.destructor.de/xmlparser/index.htm.

[freimatz]

Zitat:

Zitat von hoika (Beitrag 1430935)

Vielleicht schreibe ich mir doch was eigenes ...

Warum?

[hoika]

Hallo,
warum?
Weil es bis zu 100 mal schneller ist.

Es geht hier um 5 unterschiedliche Dateien, deren Struktur sich nicht ändert,
die aber ziemlich groß sind (50-60 MB).

Ich schaue mir die SAX-Bsp.- mal an.

Der XmlParser (destructor) sieht ja nicht schlecht aus.
Ich verstehe nur noch nicht, wie ich an die einzelnen Knoten rankomme.
Bisher greife ich über NodeByName auf das interne DOM zu.
Aber ich hatte es mir schon gedacht, das das eine komplette Code-Umstellung mit sich bringt.

[peterbelow]

Zitat:

Zitat von hoika (Beitrag 1430894)

Kennt jemand so eine Komponente?

Ich hab früher mal mit SAX for Delphi gearbeitet, hat sehr gut funktioniert. Das ist aber schon etliche Jahre her, keine Ahnung, ob der Kode mit modernen Delphi-Versionen noch funktioniert.

[hoika]

Hallo,
ich teste mal die Links durch.

Unit-Tests sind mein bester Freund...

[Luckie]

Was ist denn mit himitsus XML Unit?

[hoika]

Hallo,
ich suche noch nach einem aktuellen Download
himXML.pas 12.01.2010 ???

[Luckie]

Schreib ihn doch an.

[jobo]

Kann man davon ausgehen, dass Du einmalig lädst, vorhälst und Datenteile dann gezielt (mapping/index/..) verarbeitest?

[hoika]

Hallo,
ja, davon kannst Du ausgehen.
Ich fülle einmal eine eigene interne Struktur und benutze dann nur noch diese eigene interne Struktur.

aktuell (Pseudocode):
Xml.LoadFromFile;
AdresseNode:= Xml.NodeByName('Person').NodeByName('Adresse');
Strasse:= AdresseNode.Value['Strasse'];
HausNr:= AdresseNode.Value['HNr'];

<Person>
<Adresse>
<Strasse V="Musterweg"/>
<HNr V="3"/>
</Adresse>
</Person>

Das Problem bei mir ist, das die Datei etwa 100.000 Zeilen hat und ich davon etwa 50.000 für mein Programm brauche.

SAX würde da wohl wirklich helfen.
Ich bin mir nur nicht sicher, wie das ablaufen soll. Ich probier es einfach aus.

Noch mal zu eigenem Code.
Die Struktur ist ja fix. Jeder Node ist in einer eigenen Zeile.
Ich könnte die Datei in eine StringList laden, die dann einfach mit einer Schleife durchlaufen
und mir dir einzelnen Personen zusammensuchen.

[haentschman]

Zitat:

ich suche noch nach einem aktuellen Download

https://www.delphipraxis.net/130751-...-himix-ml.html
1. Post, ganz unten (Download)

PS: klein aber oho. 8-)

:?: himitsu ist wieder mal verschollen...

[hoika]

Hallo,

Zitat:

ganz unten.

Ja, die hatte ich mir ja runtergeladen, waren aber von 2010.
Wie ich schon weiter oben geschrieben hatte.

[haentschman]

Eine neue neuere gibt es nicht. Funktioniert auch mit aktuellem Delphi.

[hoika]

Hallo,
danke.

[hans65]

Ich hatte schon einmal den XMLParser (ALXmlDoc.pas )von https://github.com/Zeus64/alcinoe im Einsatz.
Bei meinen kurzen Tests war er schneller als das Delphi-eigene TXMLDocument.
Ein zusätzlicher Vorteil war, dass die Komponente einen Mischbetrieb zwischen Sax und Dom unterstützt. Man konnte also eine Xml-Datei nur teilweise einlesen, z.B. bis zum Ende eines Hauptknotens, alles bequem im Dom auswerten und dann freigeben und mit dem nächsten Element fortsetzen.

[jobo]

Mit dieser Struktur komme ich nur auf ca 1/5 der genannten Größe:

Code:

<Person>
    <Adresse>
        <Strasse V="Bahnhofstr."/>
        <HNr V="68"></HNr>
    </Adresse>
</Person>

[sh17]

Zitat:

Zitat von hoika (Beitrag 1430947)

Der XmlParser (destructor) sieht ja nicht schlecht aus.
Ich verstehe nur noch nicht, wie ich an die einzelnen Knoten rankomme.
Bisher greife ich über NodeByName auf das interne DOM zu.
Aber ich hatte es mir schon gedacht, das das eine komplette Code-Umstellung mit sich bringt.

Ja, solltest Du Dir mal anschauen, ein SAX Parser arbeitet nun einmal eventbasiert. Aber so groß ist die Code-Umstellung dann nicht. OXml kann mit anonymen Methoden arbeiten. Da geht das alles in einem Rutsch.

[hoika]

Hallo,

Zitat:

Mit dieser Struktur komme ich nur auf ca 1/5 der genannten Größe:

Hm ?

Zitat:

ein SAX Parser arbeitet nun einmal eventbasiert

Schon klar, ich bin ja lernfähig ;)

[jobo]

Obige Struktur mal 100000 "Datensätze" z.B. ergibt bei mir eine Datei von ca 10 MB Größe. Die Struktur ist also unvollständig, oder es gibt ein Missverständnis, jedenfalls ist ein tatsächlicher Zeitvergleich damit nicht möglich.

[Klaus01]

.. wäre es eine Möglichkeit mit Hilfe von XSLT die von Dir benötigten Daten aus dem XML File zu extrahieren?

Grüße
Klaus

[hoika]

Hallo,
ah, so meinst du das mit der Größe.
Das war nur so schnell dahingetippert.
Die Xml-Datei sieht komplett anders aus.
Deshalb auch das Pseudocode.

[jobo]

Zitat:

Zitat von hoika (Beitrag 1431027)

..das mit der Größe.
Das war nur so schnell dahingetippert.
Die Xml-Datei sieht komplett anders aus.
..

Ok, mich interessiert einfach ein realer Zeitvergleich gegen DB.
Vielleicht kannst du per copy/paste einen tatsächlichen Satz zur Verfügung stellen und das nach Bedarf anonymisieren.
Ich gehe zumindest mal davon aus, das Brutto/Netto Datenverhältnis und die durchschnittliche oder übliche Verschachtelungstiefe bei soetwas dann schon eine Rolle spielen.

[hoika]

Hallo,
nein, die realen Daten darf ich nicht rausgeben (KBV = Kassenärztliche Bundesvereinigung),
anonymisieren würde eine Menge Zeit erfordern.
Ich baue das ganze mal in meine Unit-Tests ein.
Dann sehe ich ja, ob und wie viel schneller es ist.

[Neutral General]

Er wollte ja keine ganze Datei sondern nur einen (anonymisierten) Datensatz, bzw. die Struktur

[jobo]

Schade, eine Beispiel Adresse zu anonymisieren ist so viel Aufwand? Es geht ja nur um eine exemplarische Struktur. Multiplizieren kann ich die allein.

Wenn es ein offizielles Format ist, könntest Du natürlich auch die Definition verlinken.
Aber wahrscheinlich ist es proprietäres Zeug, wie ich die kenne.

[hoika]

Hallo,
na, ganz offiziell.

ftp://ftp.kbv.de/ita-update/Stammdat...DEBM_V1.60.zip
Die Zip-Datei enthält eine alte Version der Xml-Datei im Unterverzeichnis XML (850_01.60_74_tf2017q4_nr1.xml).

[jaenicke]

Diese Alpha eines Registry Editors liest die .reg Dateien sehr schnell in eine interne Struktur ein.
Falls du es selbst versuchen möchtest, könnte dir das Ideen geben.

[hoika]

Ähem,
RegEdit ?

[jaenicke]

Es geht ja darum schnell eine Datei zu parsen, das müsste natürlich für deine Daten entsprechend anders gemacht werden. Aber z.B. die Verwendung von MMFs könntest du dir dort anschauen. Eine 400 MiB Registrydatei wird auf meinem aktuellen PC in nicht einmal 2 Sekunden (ich habe es nicht genau gemessen) eingelesen und angezeigt...
// EDIT: Es sind 1,45 Sekunden