sogar der zip-algorithmus sollte doch eine XML-Datei, die nach einem anständigen schema aufgebaut ist, nahezu auf die größe eines entsprechenden binärformats bringen... wenn man also wenig platz hat, einfach komprimieren. sowas in delphi dann zu (ent)packen, sollte auch ohne größere umstände zu machen sein.
Und die menschliche editierbarkeit halte ich jetzt persönlich für einen der größten vorzüge des formats.

_________________


"User Error. Replace User and hit Continue."

Ein reguläres Obj Model (text datei) das ich unkomprimiert in meinem eigenen (nicht optimierten) Format speichere hat bereits binär nur ein drittel der Ausgangsgröße. Gezippt komme ich auf nochmal ca 1/4 der binär größe. Ob das bei XML wirklich so ähnlich ablaufen würde wage ich zu bezweifeln.

_________________
(\__/)
(='.'=)
(")_(")

Ich habe XML aufgrund der Baumstruktur gewählt. jonas wird bestaetigen können, dass ich vorher tatsaechlich alles in Struktur von Rekords aufgebaut hatte, die den Content in .datDateien abgespeichert haben. Nun allerdings ist alles Objektorientiert und speichert in XML. Ich werd mal sehen, wieviel Speicher das braucht.
Ich finde, wenn es Festplatten mit 500gb gibt, und schon über Terrabyte große Platten gegrübelt wird, dann muss ich mir um ein Paar MB nicht mehr viele Gedanken machen. Da halte ich meinen Code dank xml lieber knapp, spare mir komprimierungen und dekomprimierungen und schone damit den RAM

Danke aber dafür, dass es codetechnisch scheinbar nix mehr auszusetzen gibt

Ja aber im Endeffekt ist XML ein offener Standard auf den unter anderem SVG, diverse Documenttypen uvm basieren. Von SVG & OpenDocument gibt es eine Variante die ihre Daten komprimiert ablegt. Bei OpenDocument ist das wohl immer der Fall. Klar wirst man mit eigenen Formaten IMMER kleiner sein. Das ist aber auch nicht sonderlich schlimm. Nur so schlägt man einen Weg ein bei dem man auf etwas zurück greift, was schon recht weit verbreitet ist und auch unterstützt wird. Schau alleine mal wie viele Möglichkeiten es gibt XML Dateien einzulesen. Das spart eine Menge Zeit und Aufwand. Und man hat so den Vorteil, dass eine flexible Strukturierungsmöglichkeit schon eingebaut ist.

Für mich ist diese Diskussion eine reine Glaubensfrage. Wenn man mit einem bestehenden Bildformat nicht einverstanden ist, dann wird einem niemand daran hindern ein eigenes Format zu entwickeln. Und genau so sehe ich das in diesem Fall. Wenn man es gerne alles selber verwalten möchte ist das okay. Und wenn man lieber ein existierendes Format benutzen möchte, dann ist auch okay. Aber ob es Sinn macht es so zu tun wie es getan wird das liegt im Ermesses eines jeden Einzelnen. Man kann nur objektiv die Vor- und Nachteile aufführen.

Und wegen ein paar hundert Kilobytes muss man heutzutag nicht diskutieren. Das ist die Mühe nicht wert. So lange es sinnvoll durchdacht ist soll das vollkommen ausreichen. Das soll jetzt nicht heißen, dass man zu verschwenderisch sein soll. Aber ein güldener Mittelweg passt schon.

Aber bitte lasst es nicht ausarten.

Es hat kein sinn xml zu kompremieren, plattenspeicher hat jeder unmengen aber xml ist verdammt langsam und hier ist der knackpunkt. man kann unmengen an geschwindigkeite sparen wenn man nur die tags als cardinal speichert und am anfang der file ein Dictonary packt. Ein tag hat dann halt ein cardinal und ein size und somit geht das überspringen von daten und das lesen von daten verdammt schnell. Ich hab momentan noch für ein Tag 9Byte und ist wie folgt aufgeteilt.
4Byte TagID,4Byte size,1Byte Flag(momentan nur enthält daten oder nicht). Daten kann man ja dann in string lassen.
Wer dann kompremieren will wird sich freuen, da dieses muster verdammt gut kompremierbar ist.
Mein Testlevel ist in xml ~19kb groß und mit zlib hats nur noch ~1,2KB.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004