Benutzerdefinierte Compiler-Warnungen

[alda]

Oder Ihr tauscht das verwendete XML Framework aus Darf man fragen um welches es sich hier handelt?

[Scurra]

Es handelt sich um NativeXml. Mein Chef meinte, am besten wäre es sowieso, wenn man nur einmal aus den xml-Dateien ließt und sich dann ein eigenes Speichermodell generiert, um den Inhalt ständig im Speicher zu halten, da wir viel mit xml-Dateien arbeiten und der Zugriff auf xml-Dateien die Software langsam macht. Aus Mangel an Erfahrung wüsste ich nicht, ob das wirklich so ist.
Allerdings finde ich es schon beeindruckend, dass man durch das Ändern von einem Parameter wie bei der oben genannten Methode die Laufzeit bei manchen Prozessen um einen Faktor von mehr als 2 verkürzen kann. Die Anzahl der Funktionsaufrufe an die Methode konnte ich vom 6-stelligen in den 3-stelligen Bereich reduzieren

[jfheins]

Zitat von Scurra:

Mein Chef meinte, am besten wäre es sowieso, wenn man nur einmal aus den xml-Dateien ließt und sich dann ein eigenes Speichermodell generiert, um den Inhalt ständig im Speicher zu halten, da wir viel mit xml-Dateien arbeiten und der Zugriff auf xml-Dateien die Software langsam macht. Aus Mangel an Erfahrung wüsste ich nicht, ob das wirklich so ist.

Höchstwahrscheinlich schon. Am besten am Anfang einmal die Datei laden, alles im RAM machen und dann am Ende wieder einmal (am Stück) schreiben. Sofern der RAM die Daten halten kann. Bedenke, Zugriffszeiten auf dem RAM sind so 60 Nanosekunden, auf schnelle SSDs noch 9 Mikrosekunden.

Oder zur besseren Vorstellung: Wenn ein CPU-Zyklus 1 Sekunde lang ist, dauert RAM-Zugriff 180s. Also wenn die Info auf einem Zettel steht (weil du es dir nicht mehr merken konntest) die Zeit wenn du den Zettel im Nebenraum in einem Schrank suchen müsstest.
Die (moderne, schnelle) SSD dauert dann 7,5h! Du kannst den Zettel Papier also schnell aus einer 350km entfernten Stadt abholen Und das ist eine schnelle SDD. Eine HDD braucht in der Skalierung ein ganzes Jahr um dir den Zettel zu liefern!

[Scurra]

Danke für die Veranschaulichung. Es wundert mich nur, dass es so lange dauert, denn zum Teil halten wir den Inhalt der xml-Dateien schon im Speicher, also in Form eines xml-Dokuments (TNativeXml). Anscheinend dauert aber der Zugriff auf solche xml-Dokumente immer noch relativ lange, weshalb man wohl z. B. Listen o. ä. verwenden könnte, um den Inhalt der xml-Dateien im Speicher zu halten.

[alda]

Zitat von jfheins:

Höchstwahrscheinlich schon. Am besten am Anfang einmal die Datei laden, alles im RAM machen und dann am Ende wieder einmal (am Stück) schreiben. Sofern der RAM die Daten halten kann. Bedenke, Zugriffszeiten auf dem RAM sind so 60 Nanosekunden, auf schnelle SSDs noch 9 Mikrosekunden.

Also die Implementierung sieht mir danach aus, dass bereits alles per LoadFrom* eingelesen wird und somit nicht nochmal extra von Platte gelesen werden muss. Man müsste sich das mal im Detail anschauen, aber abhängig von der Größe und Komplexität der XML-Datei hat man eben abertausende Node & Attribute Objekte die komplett durchsucht werden bis der gewünschte Knoten gefunden wird.

Die Frage ist daher in der Tat (hab gerade leider kein Delphi zur Hand), ob es an der NativeXML Implementierung liegt oder an einem "zu großen" XML.

Im allgemeinen würde ich sowieso grundsätzlich empfehlen beim "in ein XML greifen" mit XPath zu arbeiten - so könntest Du unabhängig von der jeweiligen Implementierung selbst angeben ob rekursiv gesucht werden soll oder nicht (Stichwort Axes). Soweit ich sehe unterstützt NativeXML aber kein Xpath, oder irre ich mich?

[Sir Rufo]

Dein Chef hat Recht. Wenn du nicht gerade ein XML-Validierungs-Import-Export-Programm schreibst, dann gehört der Umgang mit den XML-Dateien an den Rand der Anwendung und nicht in den Kern (obwohl, selbst dann sogar )

[Scurra]

Zitat:

Soweit ich sehe unterstützt NativeXML aber kein Xpath, oder irre ich mich?

Dazu kann ich leider noch nichts sagen, da ich XPath gerade zum ersten Mal höre So wie ich das auf die Schnelle gelesen habe, stellt XPath Funktionen bereit, um durch xml-Dokumente zu navigieren. Ist das richtig so?

Zitat:

Dein Chef hat Recht. Wenn du nicht gerade ein XML-Validierungs-Import-Export-Programm schreibst, dann gehört der Umgang mit den XML-Dateien an den Rand der Anwendung und nicht in den Kern (obwohl, selbst dann sogar )

Na ja, ich ging bisher immer davon aus, dass ein xml-Parser nichts anderes macht, als den Inhalt eines xml-Dokuments in sein eigenes Speichermodell (wie auch immer das aussehen mag) liest. Wenn ich mir selbst einen Parser schreiben würde, dann würde ich das zumindest auf diese Weise machen, d. h. die .xml-Datei wie als Text-Datei betrachten und mir die Knoten, die Struktur usw. mit Listen o. ä. in den Speicher einlesen (mit einer Methode wie LoadFromFile) und wenn ich dann mit Methoden wie "GetNode(Integer)" o. ä. würde ich dann in meinem Speichermodell operieren. Insofern ist mir nicht ganz klar, warum das Arbeiten direkt mit xml-Dateien/xml-Dokumenten langsamer sein soll.

Aber mir fällt auch gerade auf, dass wir durch diese xml-Geschichte vom eigentlichen Thema abkommen

[alda]

Zitat von Scurra:

Zitat:

Soweit ich sehe unterstützt NativeXML aber kein Xpath, oder irre ich mich?

Dazu kann ich leider noch nichts sagen, da ich XPath gerade zum ersten Mal höre So wie ich das auf die Schnelle gelesen habe, stellt XPath Funktionen bereit, um durch xml-Dokumente zu navigieren. Ist das richtig so?

XPath ist eine Querylanguage und hat somit eine entsprechende Syntax zum abfragen von XML Strukturen. Schau Dir dazu einfach mal ein Tutorial an (z.B. w3schools)

Zur Veranschaulichung mal ein kleines Beispiel anhand deines Anwendungsfalls:

Gegeben sei folgende XML Struktur

Code:

<?xml version="1.0" encoding="UTF-8"?>
<bookstore>
  <book category="COOKING"/>
  <book category="CHILDREN"/>
  <book category="WEB"/>
  <book category="WEB"/>
  <usedbooks>
    <book category="WEB"/>
    <book category="COOKING"/>
    <book category="MISC"/>
  </usedbooks>
</bookstore>

XPath Query um ..

• alle Knoten books mit der category "WEB" zu erhalten, allerdings nicht rekursiv (also nur auf bookstore Ebene):
  //bookstore/book[@category="WEB"]
• alle Knoten books mit der category "WEB" zu erhalten, allerdings rekursiv (somit auch im usedbooks Knoten)
  //bookstore//book[@category="WEB"]

[Sir Rufo]

Zitat von Scurra:

Zitat:

Dein Chef hat Recht. Wenn du nicht gerade ein XML-Validierungs-Import-Export-Programm schreibst, dann gehört der Umgang mit den XML-Dateien an den Rand der Anwendung und nicht in den Kern (obwohl, selbst dann sogar )

Na ja, ich ging bisher immer davon aus, dass ein xml-Parser nichts anderes macht, als den Inhalt eines xml-Dokuments in sein eigenes Speichermodell (wie auch immer das aussehen mag) liest. Wenn ich mir selbst einen Parser schreiben würde, dann würde ich das zumindest auf diese Weise machen, d. h. die .xml-Datei wie als Text-Datei betrachten und mir die Knoten, die Struktur usw. mit Listen o. ä. in den Speicher einlesen (mit einer Methode wie LoadFromFile) und wenn ich dann mit Methoden wie "GetNode(Integer)" o. ä. würde ich dann in meinem Speichermodell operieren. Insofern ist mir nicht ganz klar, warum das Arbeiten direkt mit xml-Dateien/xml-Dokumenten langsamer sein soll.

Aber mir fällt auch gerade auf, dass wir durch diese xml-Geschichte vom eigentlichen Thema abkommen

Es ist nicht gesagt, dass der alles im Speicher halten muss, kann ja. Um das herauszufinden, müsstest du dir die Implementierung ansehen.

Egal, wie und was, mit ein paar leichtgewichtigen Klassen kannst du die Struktur wesentlich einfacher abbilden und musst nicht den ganzen XML-Ballast mit dir herumschleppen.

Statt dich hier durchzukämpfen um ein Buch anzuhängen:

XML-Code:

<?xml version="1.0" encoding="UTF-8"?>
<bookstore>
  <newbooks>
    <book category="COOKING"/>
    <book category="CHILDREN"/>
    <book category="WEB"/>
    <book category="WEB"/>
  </newbooks>
  <usedbooks>
    <book category="WEB"/>
    <book category="COOKING"/>
    <book category="MISC"/>
  </usedbooks>
</bookstore>

erstellst du dir (hier zwei) Klassen um die benötigte Struktur abzubilden:

Delphi-Quellcode:

TBook = class
  property Category: string;
end;

TBookstore = class
  property NewBookes: TList<TBook>;
  property UsedBooks: TList<TBook>;
end;

Und dann hast du einen Serializer/Desrializer, der dann beim Import/Export zu Tragen kommt:

Delphi-Quellcode:

// Holen
LBookstore := TXmlSerializer.Deserialize<TBookstore>( XmlData );

// Wildeste Verarbeitungen durchführen
LBookstore.NewBooks.Add( TBook.Create() );

// Und so bekommen wir das wieder in eine XML-Datei
TXmlSerializer.Serialize( LBookstore, XmlData );

Nur so vom Anschauen: Was ist deiner Meinung nach schneller (und sogar noch einfacher) in der Verarbeitung?