Benutzerdefinierte Compiler-Warnungen

[Scurra]

Hallo zusammen,

ich habe vor kurzem die Performance einer Software überprüft und mir ist aufgefallen, dass es eine Stelle gibt, an der die Performance sehr schlecht ist: Man hat dort eine Methode NodeByAttributeValue eines Xml-Knotens, die Sub-Knoten mit einem bestimmten Namen, Attributnamen und Attributwert sucht. Es gibt zusätzlich einen Methodenparameter "Should-Recurse: Boolean = True", der angibt, ob die Methode auch rekursiv die Sub-Knoten selbst durchsuchen soll.

Das Problem dabei ist, dass wir das in der Regel nicht möchten, da wir meistens schon direkt zum Vater-Knoten navigieren.

In unserer Software wird der Parameter in der Regel nicht explizit angegeben, da das bislang niemandem aufgefallen ist. Jetzt möchten wir die Performance verbessern. Da diese Methode aus einer Fremdkomponente stammt, möchten wir nicht einfach den Default-Wert des Parameters auf False setzen. Es ist auch kein Problem, an allen Stellen, an denen wir die Methode aufrufen, nachträglich explizit ein false zu übergeben.


Meine Frage ist nun, ob es möglich ist, in diesem speziellen Fall eine Compiler-Meldung ausgeben zu lassen, wenn man den Parameter ShouldRecurse beim Methodenaufruf nicht explizit angegeben hat, damit man den Fehler später nicht noch einmal macht oder zumindest auf den Fehler hingewiesen wird ;) Ich konnte bisher leider nichts finden und ich glaube auch eher nicht, dass es möglich ist, denn wenn man den Default-Parameter explizit angeben möchte, warum entfernt man dann nicht einfach den Default-Wert? In unserem Fall ist der Grund (wie oben schon erwähnt) dass es sich um eine Fremdkomponente handelt, die wir nicht ändern möchten.

[gammatester]

Meinst Du vielleicht sowas in der Art?

Delphi-Quellcode:

{$message HINT 'So vielleicht nicht!'}
{$message ERROR 'So nicht!'}
{$message WARN 'So nicht!'}

[Der schöne Günther]

Aber ihr könnt den Quellcode ändern, oder? Wie wäre es mit einer

Delphi-Quellcode:

deprecated

-Direktive für die Überladung mit dem Default-Parameter?

[Scurra]

Danke euch beiden für die schnelle Hilfe!

Zitat:

Zitat von gammatester (Beitrag 1310302)

Meinst Du vielleicht sowas in der Art?

Delphi-Quellcode:

{$message HINT 'So vielleicht nicht!'}
{$message ERROR 'So nicht!'}
{$message WARN 'So nicht!'}

Na ja, so wie ich das sehe, besteht hier das Problem, dass ich diese Anweisung immer an die Stelle schreiben muss, an der ich die Methode NodeByAttributeValue aufrufe. Mir geht es darum, den Programmierer, der nicht weiß, dass es an der Methode einen Haken gibt, zu warnen, aber nur, falls er den Default-Parameter beim Methodenaufruf nicht explizit setzt.

Zitat:

Aber ihr könnt den Quellcode ändern, oder? Wie wäre es mit einer deprecated -Direktive für die Überladung mit dem Default-Parameter?

Ja, das können wir. Das mit der deprecated-Direktive ist auch eine gute Idee. Allerdings mit 2 Seiteneffekten: Falls die Methode NodeByAttributeValue von der Fremdkomponente selbst irgendwo verwendet wird, dann sollte ich auch diese Aufrufe alle anpassen, sonst bekomme ich immer Warnungen. Und den Code der Fremdkomponente müssten wir dann natürlich auch ändern (neue Methode hinzufügen). Vllt wäre es dann einfacher, den Default-Parameter zu ändern :)

Ich habe schon erwartet, dass es nicht so funktioniert, wie ich mir das vorgestellt habe, aber vllt. findet ja doch noch jemand eine Lösung. Sonst werden wir wohl den Code der Fremdkomponente ändern müssen ;)

[alda]

Oder Ihr tauscht das verwendete XML Framework aus :P 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 :D

[jfheins]

Zitat:

Zitat von Scurra (Beitrag 1310441)

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:

Zitat von jfheins (Beitrag 1310442)

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 ;))