Schnelle XML Lib für große Dateien gesucht

[Mithrandir]

Zitat:

Zitat von Elvis

Was spricht denn gegen den guten alten XmlReader aus dem .Net Framework?

:gruebel:

Eventuell die Angabe der Delphiversion in meinem Profil :stupid:

Zitat:

Turbo Delphi für Win32

Oder kann ich Win32 und .NET mischen? Nee, eigentlich doch nicht.. :gruebel:

[TurboMartin]

Solltest Du MySQL nutzen, könnte ja auch das hier für dich von interesse sein :stupid:

[himitsu]

Zitat:

Zitat von Daniel G

Allerdings bekomme ich bei der großen 4 GB Datei den E/A-Fehler 998.

Zitat:

Zitat von Daniel G

Ich habe mal geguckt, er hängt bei dieser Funktion

deswegen solltest du bei nahezu allen XML-Parsern probleme bekommen, da sie oftmals erstmal die gesamte Datei in den RAM laden und darun dann parsen.

Gut, mein Parser läuft nur stückchenweise und läd größere Dateien möglichst nur in 64 KB-Stückchen, aber dennoch landet der XML-Tree danach im RAM, wie bei vielen anderen Parsern.

Bei mir würde da allerdings eine 1 GB-Datei nur maximal + 64 KB (für's Laden) ~1 GB (die Daten) + ein paar Byte je für je 2 Objekte pro Node belegen, wärend es bei anderen dann 1 GB (für's Laden) + ~1 GB (die Daten) + die Verwaltung ... ja und dann kommt noch die fragmentierung des Speichermanagers dazu ....... also bei über weit 1 GB bekommst du so oder so arbe Probleme diese in ein 32-Bit-Delphi-Programm reinzubekommen, wo nur ~2 GB zur Verfügung stehen.

Wenn mein aktuelles XML-Projekt mal steht, ist zwar noch ein weiterter Parser geplant, welcher dann mit größeren Dateien klar kommen sollte, aber von schnell kann dann nicht mehr die Rede sein, da dieser dann einen Großteil der Daten direkt auf der "langsamen" Festplatte lagert, bzw, liegen läßt.

[Mithrandir]

Irgendwie ist das alles... :kotz:

Ich hab jetzt also im Prinzip zwei Möglichkeiten: Entweder versuche ich der Lib beizubringen, eine Datei stückchenweise einzulesen, das Eingelesene zu verarbeiten und dann den Puffer für das nächste Stück freizugeben, oder ich nutze gleich eine andere Implementation... :?

[himitsu]

Zitat:

Zitat von Daniel G

Entweder versuche ich der Lib beizubringen, eine Datei stückchenweise einzulesen...

und das ist nicht so einfach ... was denkst du denn, warum ich etwas an der "Leseprozedur" festhänge? :roll:

[Muetze1]

Zitat:

Zitat von himitsu

deswegen solltest du bei nahezu allen XML-Parsern probleme bekommen, da sie oftmals erstmal die gesamte Datei in den RAM laden und darun dann parsen.

Oder einfach MMF nutzen, dann wird gemappt (stückchenweise) und nichts explizit in den Speicher gehauen.

Zitat:

Zitat von himitsu

..... also bei über weit 1 GB bekommst du so oder so arbe Probleme diese in ein 32-Bit-Delphi-Programm reinzubekommen, wo nur ~2 GB zur Verfügung stehen.

So lange die Arbeit mit den Zeigern und offsets nicht mit vorzeichenbehafteten Typen von statten geht, kann man leicht mit FastMM und der $SetPEFlags Compilerdirektive die 3,2 GB nutzbar machen. Ich setze es in ein ein paar Projekten ein (auch grosse) und das klappt einwandfrei. Dann hat man nochmal immerhin 1.2 GB weiteren Spielraum.

/EDIT: zu den MMF: Wenn die XML Lib es unterstützt aus einem TStream Nachfahren zu Laden, dann nutze die MMF Filestream Implementation aus meiner XMLLib. Diese implementiert das MMF transparent ohne das der Nutzer des TStream Nachfahren was davon bemerkt.

[Daniel]

Wie wäre es denn, sog. "Memory Mapped Files" zu verwenden? Aus Sicht Deiner Anwendung läge die gesamte Datei dann im Speicher und Du kannst mit einem Pointer komplett drüberrutschen. Welche Fetzen der Datei dann tatsächlich im Speicher sind und welche nicht, übernimmt dann das OS.

//edit: gnapf ... zu langsam :stupid:

[himitsu]

Solange aber ein Node nicht in den gemappten Bereich reinpaßt, muß man mehr Seicher nachmappen ... ist alles schon ein klein bissl aufwändiger. (hatte es anfangs auch mal über MMF, aber es dann doch etwas anders gelöst :angel2: )

oder man mappt die gesamte Datei in den RAM, aber daß hat auch wieder einen kleinen Nachteil ... die Datei müßte dann meistens als ein Stück vorliegen und die müssen erstmal zusammenhängend vorliegen und dann wäre ein ganzes Stück vom virtuellen Speicher belegt.

[Muetze1]

Zitat:

Zitat von himitsu

..., aber daß hat auch wieder einen kleinen Nachteil ... die Datei müßte dann meistens als ein Stück vorliegen und die müssen erstmal zusammenhängend vorliegen und dann wäre ein ganzes Stück vom virtuellen Speicher belegt.

Was meinst du mit "als ein Stück vorliegen"? Das OS kümmert sich beim anlegen des Mappings darum wo die Datei liegt. Du musst dir keine Sorge darum machen, dass das Dateisystem diese zusammenhängend irgendwo hingeschrieben hat. Das ist nicht deine Aufgabe und geht dich als WinAPI Anwender nichts an. Dies ist keine Voraussetzung zur Nutzung von MMF!

[Mithrandir]

Zitat:

Zitat von Muetze1

Oder einfach MMF nutzen, dann wird gemappt (stückchenweise) und nichts explizit in den Speicher gehauen.

Hmm, klingt interessant... :gruebel:

Zitat:

Zitat von Muetze1

So lange die Arbeit mit den Zeigern und offsets nicht mit vorzeichenbehafteten Typen von statten geht, kann man leicht mit FastMM und der $SetPEFlags Compilerdirektive die 3,2 GB nutzbar machen. Ich setze es in ein ein paar Projekten ein (auch grosse) und das klappt einwandfrei. Dann hat man nochmal immerhin 1.2 GB weiteren Spielraum.

Und dann kommt einer auf die Idee, das sog. Planet-File einzulesen. Gepackt 5 GB groß, entpackt das 6-fache. Ich hätte vielleicht auch noch erwähnen sollen, dass die Dateien netterweise Zeilenumbrüche besitzen... :stupid:

Damit ihr mal seht, worüber wir eigentlich die ganze Zeit philosophieren:

So sieht eine OSM-Datei aus:

XML-Code:

  
//Header

<?xml version='1.0' encoding='UTF-8'?>
<osm version="0.5" generator="Osmosis 0.29">
<bound box="53.35408,8.05388,55.09603,12.03859" origin="http://www.openstreetmap.org/api/0.5"/>

//Paar tausend Zeilen übersprungen
<node id="13345659" timestamp="2008-12-14T16:57:25Z" user="Gluko" lat="53.9024873" lon="10.777812"/>
<node id="13345660" timestamp="2008-12-14T16:59:07Z" user="Gluko" lat="53.90483" lon="10.779308"/>
<node id="13345661" timestamp="2008-12-14T16:58:56Z" user="Gluko" lat="53.9045348" lon="10.7796025"/>
<node id="13345662" timestamp="2009-01-23T14:08:35Z" user="itschytoo" lat="53.899494" lon="10.7674726"/>
<node id="13345663" timestamp="2009-03-22T10:48:30Z" user="itschytoo" lat="53.8993371" lon="10.7675229"/>
<node id="13345664" timestamp="2009-01-23T14:08:35Z" user="itschytoo" lat="53.8989988" lon="10.7644318"/>
<node id="13345665" timestamp="2009-02-28T14:21:15Z" user="Maarten Deen" lat="53.8985106" lon="10.759474">
  <tag k="barrier" v="toll_booth"/>
  <tag k="name" v="Herrentunnel Lübeck Nord"/>
  <tag k="operator" v="Herrentunnel Lübeck GmbH &amp; Co. KG"/>
</node>
<node id="13345670" timestamp="2009-01-23T14:08:35Z" user="itschytoo" lat="53.8986935" lon="10.7615206"/>
<node id="13345672" timestamp="2009-01-23T14:08:35Z" user="itschytoo" lat="53.8984061" lon="10.7579444"/>
<node id="13345673" timestamp="2009-03-19T14:20:45Z" user="itschytoo" lat="53.8971746" lon="10.7492752"/>
<node id="13345674" timestamp="2009-01-23T14:08:45Z" user="itschytoo" lat="53.8980463" lon="10.7543967"/>
<node id="13345680" timestamp="2009-03-22T10:48:29Z" user="itschytoo" lat="53.8976444" lon="10.7523478"/>
<node id="13345681" timestamp="2009-03-19T14:23:04Z" user="itschytoo" lat="53.8972377" lon="10.7511739"/>
<node id="13345683" timestamp="2009-03-19T14:24:27Z" user="itschytoo" lat="53.8952786" lon="10.7510925"/>
<node id="13345685" timestamp="2008-09-01T07:03:44Z" user="Lübeck" lat="53.8949418" lon="10.7519724">
  <tag k="created_by" v="JOSM"/>
  <tag k="highway" v="traffic_signals"/>
</node>

//Paar tausend Zeilen übersprungen

<way id="27190543" timestamp="2008-09-20T10:34:08Z" user="phobie">
  <nd ref="275411385"/>
  <nd ref="275411386"/>
  <nd ref="274748737"/>
  <tag k="name" v="Lindenweg"/>
  <tag k="highway" v="residential"/>
</way>
<way id="27190544" timestamp="2008-09-20T10:34:09Z" user="phobie">
  <nd ref="274748080"/>
  <nd ref="298365383"/>
  <nd ref="298365384"/>
  <tag k="noexit" v="yes"/>
  <tag k="highway" v="service"/>
</way>

//Wieder ein paar hundertausend Zeilen übersprungen

<relation id="16007" timestamp="2009-04-13T07:20:56Z" user="UncleOwen">
  <member type="way" ref="24737571" role=""/>
  <member type="way" ref="24737575" role=""/>
  <tag k="name" v="Liebermannweg"/>
  <tag k="route" v="road"/>
  <tag k="created_by" v="JOSM"/>
  <tag k="type" v="route"/>
</relation>

<relation id="16008" timestamp="2009-04-13T07:20:56Z" user="UncleOwen">
  <member type="way" ref="21107760" role=""/>
  <member type="way" ref="24737566" role=""/>
  <member type="way" ref="24737581" role=""/>
  <tag k="name" v="Luise-Schröder Ring"/>
  <tag k="route" v="road"/>
  <tag k="created_by" v="JOSM"/>
  <tag k="type" v="route"/>
</relation>

<relation id="16010" timestamp="2009-04-13T07:20:55Z" user="UncleOwen">
  <member type="way" ref="22672888" role=""/>
  <member type="way" ref="24737825" role=""/>
  <member type="way" ref="24737826" role=""/>
  <member type="way" ref="26248001" role=""/>
  <member type="way" ref="28090656" role=""/>
  <member type="way" ref="28090657" role=""/>
  <tag k="name" v="Esinger Weg"/>
  <tag k="route" v="road"/>
  <tag k="created_by" v="JOSM"/>
  <tag k="type" v="route"/>
  <tag k="highway" v="residential"/>
</relation>

//Ende

</osm>