Eigen erstellte PC-Software (Hardware Testprogramm mit Multimeter) bringt komplizierte Nachverfolgung und Reporterstellung mit sich. Deshalb versuche ich jetzt, ein XML-Logfile zu erzeugen, das eine große Anzahl Ereignisse in der Form: <LogEvent timestamp="" message=""><OptionalInfo>...</OptionalInfo></LogEvent> stets mitschreibt. Ausnahmen von Threads, Testabläufen und grafischen Steuerlementen sollen auch mitgeschrieben werden. Auch Messergebnisse. Man könnte auch einen XSyslog-Dienst einrichten der eine Kopie hält. Wird eben bei dem Log-Event noch ein Herkunftsattribut eingefügt. Zunächst steht in dem Logfile aber noch kein XML Rootelement. Somit kann immer angehängt werden. Zu Auswerten klammert man eine Kopie des Logfiles noch in ein <root>...</root> - Element. Wozu kann man es nutzen? - Man muss auf den Schutz persönlicher Daten achten. Daher eher für Technik-SW geeignet. - Aus dem Logfile kann man einen Auszug mit den Messergebnissen für ein bestimmtes Testobjekt anfertigen (wieder XML). Daraus kann XSLFO einen PDF-Report erzeugen. - Es sind auch aufgetretene Ausnahmen in Zusammenhang mit Messergebnissen enthalten (z.B. Division durch NULL, zu Ende geführter Test trotz Ausnahme, der nicht gültig ist aber Fehlerinformationen enthält). - Ein Editor, dessen Fensterposition mitgeloggt wurde, kann beim nächsten Start das Logfile fragen und mit dieser Fensterposition wieder öffnen. - Undo-Funktionen würden auch weit zurückreichen. Mal sehen, was sich aus dem XML alles so herausgreppen lässt...
2 cent: Ich persönlich arbeite eigentlich lieber mit zeilenorientierten Daten weil die Weiterverarbeitung mit grep und Ecxel deutlich flüssiger von der Hand geht. Für die coolen Leute ist sicher noch ein einfacher Input in R wichtig.
Aha, XML. Was sagt die W3C, Hüterin des XML-Standards, noch mal über XML? Ach ja: >> ... the main properties that are considered lacking from XML are >> Compactness and Processing Efficiency, ... Daher ist XML in der Tat ein hervorragender Ansatz wenn die Mission ist, dass jeder Embedded-Computer in Zukunft mindestens ein 8-Kern CPU mit 2 GHz Taktfrequenz und 16 GB Hauptspeicher benötigt. Für verbesserte Wirkung, und im Hinblick auf das Missionsziel, würde ich ein professionelles XML-Format empfehlen, wie es für wirklich große, komplizierte Systeme eingesetzt wird. Etwas, bei dem alleine schon der Titel der Spezifikation Fans der gepflegten Komplexität Freudentränen in die Augen treibt. https://www.etsi.org/deliver/etsi_ts/132400_132499/132435/15.00.00_60/ts_132435v150000p.pdf >>> Digital cellular telecommunications system (Phase 2+) (GSM); >>> Universal Mobile Telecommunications System (UMTS); >>> LTE; >>> Telecommunication management; >>> Performance measurement; >>> eXtensible Markup Language (XML) file format definition >>> (3GPP TS 32.435 version 15.0.0 Release 15)
Habe es jetzt propiert. Jeder Logeintrag ist eine Zeile. Mit dem RandomAccessFile extrahierte ich Byte für Byte rückwärts aus dem File bis eine Zeile erreicht war. Bei falschem Treffer notierte ich die letzte Position und machte mit der vorletzten Zeile weiter. Ich kettete alle Bytes der Zeile zusammen. Dummerweise kam so das XML Element rückwärts raus. Seitdem kette ich rückwärts damit das XML Element vorwärts entsteht. Somit startet die Anwendung stets mit der letzten Fensterposition.
Claus W. schrieb: > Habe es jetzt propiert. > > Jeder Logeintrag ist eine Zeile. Mit dem RandomAccessFile extrahierte > ich Byte für Byte rückwärts aus dem File bis eine Zeile erreicht war. > Bei falschem Treffer notierte ich die letzte Position und machte mit der > vorletzten Zeile weiter. Ich kettete alle Bytes der Zeile zusammen. > Dummerweise kam so das XML Element rückwärts raus. Seitdem kette ich > rückwärts damit das XML Element vorwärts entsteht. > > Somit startet die Anwendung stets mit der letzten Fensterposition. ??? Sorry, aber ich verstehe nur Bahnhof. Welche Fensterposition? Warum XML von Hand parsen? merciless
Ich habe ein PC-Programm geschrieben, das Embedded-Geräte mit dem Dmm messen soll. Das PC-Programm macht ein Fenster auf und zeigt in einem Scrollbereich sämtliche Testschritte an. Beim Schließen des Fensters wird die Fensterposition, Fenstergröße, Scrollposition und der Name der geöffneten Datei in das Logfile geschrieben. Und zwar als einzelnes XML-Element das genau eine Zeile braucht. Für nähere Hinweise kann in dieses Element auch ein Kindelement eingebaut werden aber ohne die Zeile zu wechseln. Es kommt aber nicht alles in das Logfile, einige Dinge werden auch einfach verworfen. Das Auslesen des Files erfolgt, indem vom Ende des Files jeweils eine Zeile kopiert wird. Aus dieser erzeuge ich ein Xml-Document das nur aus dem Inhalt dieser einen Zeile besteht. So kann ich von drei, vier letzten Zeilen mehrere kleine XmlDocumente erzeugen oder auch deren Inhalte kombinieren. Auf die Art könnte ich auch eine Undo-Funktion implementieren oder die letzten fünf geöffneten Dateien auflisten, wenn es mal soweit kommt. Ein gesamter Testlauf könnte somit ein Start-Logeintrag und ein End-Logeintrag schreiben. Dazwischen kämen sämtliche Messergebnisse. Somit ist alles rückverfolgbar.
Ich halte XML für keine gute Wahl für soetwas. Nimm lieber JSON. Es ist immer möglich ein JSON Objekt in eine einzige Zeile zu Packen, und die Datenstruktur ist einfacher.
Also ich denke du vermischst hier 2 Dinge: Logfiles dienen normalerweise nur der Protokollierung. Diese werden danach vielleicht ausgewertet. Das was du aber auch darin speichern möchtest, ist ein Zustand deines Programmes, den du beim erneuten Start wiederherstellen willst (so eine Art Session). Hast du nur ein Logfile, oder erzeugst du verschiedene (für jede Messung eines)? Willst du diesen Zustand für alle Messungen gemeinsam speichern oder für jede Messung separat? Auch halte ich XML für diese Art Anwendung als nicht geeignet: XML dient normalerweise dem Datenaustausch mit anderen System, evtl. noch als Ersatz für ini-Configfiles. Für alles andere gibt es bessere Lösungen. Hast du mal an eine Datenbank gedacht (SQLite)? merciless
Es ergeben sich tatsächlich Performance-Probleme beim Programmstart wenn man um die 1000 Zeilen zurücklesen muss. Wahrscheinlich benötigt der Konstruktor für das XmlDocument einige CPU-Zeit.
Es kam zu Performance-Problemen weil das File 2MByte lang ist (und wächst) und öfter schnell mal gelesen werden muss. Festplatten benötigen eine geringere Zeit um den Schwenkarm zu positionieren und eine etwas längere Zeit damit sich die Platte auf den entsprechenden Winkel dreht. Das würde Vorwärtslesen gegenüber Rückwärtslesen bevorzugen. Z.B. wären 6000 U/min => 600U/s => 600 Hz. Der Bereich des Rückwärtslesens wäre bei mir auf etwa 2MByte begrenzt aber Rückwärtslesen ohne Block dauert damit fünf Sekunden pro Suche. Falls Festplatten mit FLASH optimiert sind ist mir die Geschwindigkeit des Rückwärtslesens unbekannt (weiß nicht ob ich eine FLASH-Platte habe) aber ich rechne mit längerer Dauer für das Rückwärtslesen. Somit habe ich optimiert auf jeweils einen Block von 4kByte vom Ende beginnend vorwärts zu lesen und in XML zu parsen worauf später der Vorgänger dieses Blockes folgt. => Parsen: Mit dem StringBuilder in das <root>-Element verpacken. => Beginn des Blockes finden: Ausnahmsweise byte für byte einzeln rückwärts lesen bis der Zeilentrenner erreicht ist. Somit kann man die 2MByte in weniger als einer Schrecksekunde lesen. Im Taskmanager sieht man keinen hohen CPU-Verbrauch.
Erde an Claus, Erde an Claus, hast Du die Kommentare hier verstehen können? Warum XML, warum rückwärts, warum zeilenweise XML (statt zeilenweise ODER XML)?
Claus W. schrieb: > Es kam zu Performance-Problemen weil das File 2MByte lang ist (und > wächst) und öfter schnell mal gelesen werden muss. Dann nimm eine Datenbank wenn du das Ding wie eine Datenbanktabelle benutzen willst, genau dazu wurden Datenbanken erfunden und hochgradig optimiert damit man eine Datenbank benutzen kann wenn eine Datenbank braucht und sich keine eigene Datenbank schreiben muss welche dann mit Unzulänglichkeit und unterirdischer Performance glänzen würde so wie Deine selbstgebastelte Datenbankattrappe.
Als Datenbank könnte dann sqlite für dich interessant sein. Die Datenbank ist dann auch nur eine Datei.
Wieder ein Fall von "Pfuscher verwendet wieder ohne Hirn und Verstand Technik X von der mal gehört hat dass das toll wäre". Kennst du überhaupt die Vorteile wo man besser XML verwendet und wann nicht? Da würde ich erst mal ansetzen, sieht nämlich nicht so aus. Denk mal nach warum XML für dein Vorhaben von Vorteil oder Nachteil wäre, danach entscheidet man sich. Wenn ich schon lese "aus XML herausgreppen" da ist ja schon Hopfen und Malz verloren.
Wegen 2MB rückwärts lesen? In mehrere 4KB Häppchen? Das ist: Blödsinn. Lies die 2MB am Stück, ganz normal, mit einem XML-Parser ein. Dann den letzten XML-Node, der interessiert, verwenden. Fertich. Dauert ca. 50ms.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.