Laden...

[Erledigt] Textdatei mit Messergebnissen effizient einlesen/mappen

Erstellt von Killerkrümel vor 5 Jahren Letzter Beitrag vor 5 Jahren 1.755 Views
K
Killerkrümel Themenstarter:in
166 Beiträge seit 2008
vor 5 Jahren
[Erledigt] Textdatei mit Messergebnissen effizient einlesen/mappen

Hallo Community,

Ich habe eine Textdatei, welche ≥ 5000 Zeilen Text (Messergebnisse eines Runs eines Messgerätes) enthält. Die ersten 10 Lines eines Blocks sind dabei immer Metadaten (Ein Block ist etwa 100 Zeilen Lang).

Die Frage, die sich mir stellt, ist,
ob es neben StreamReadern, Buffered Readern, ReadLines/ReadLine eine einfache Lösung gibt, um
nicht jede Zeile der Datei einzeln betrachten zu müssen, oder vllt einen Ansatz für einen Mapper, welcher mir Blockweise aus der Textdatei daten holt und in eine Structur umwandelt.

Viele Grüße,
Killerkruemel

T
2.219 Beiträge seit 2008
vor 5 Jahren

Geht halt nur über Zeilen zählen oder du liest über den StreamReader/File einfach den gesamten Text ein.
5000 Zeilen klingen erst einmal nicht nach viel und sollten auch ohne Probleme in den Speicher passen.
Dann kannst du den Textblock oder eben die Zeilen Blöcke im RAM parsen.
Je nach dem wie aufwendig dies ist, könntest du auch schauen ob du deine Blöcke mit Tasks asynchron parsen lässt.
Dann verringerst du nochmal die Laufzeit etwas, wenn diese den hoch sein sollte.

Ansonsten müsste man wissen wie die Dateien aussehen und wo dein eigentliches Problem liegt.
Das lesen einer Datei Zeile für Zeile geht i.d.R. auch recht schnell.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

K
Killerkrümel Themenstarter:in
166 Beiträge seit 2008
vor 5 Jahren

Hallo T-Virus.

Es gibt eigentlich kein Problem, ich suche lediglich nach einer (vllt schon vorhandene Möglichkeit) eine Recht Große Textdatei (vllt mit Offset) einlesen und verwerten könnnen.

Dachte - da ich auch QuickIO kenne - das es etwas ähnliches für Textdateien gibt 😃

T
2.219 Beiträge seit 2008
vor 5 Jahren

@Killerkrümel
In welchem Format liegen die Daten in der Textdatei?
Ist dies ein Custom Textformat oder z.B. JSON oder XML?
Wenn die JSON oder XML ist, könntest du die Daten durch Deserialisierung auslesen, dann müsstest du nicht selbst parsen.

Wenn du sogar das Format ändern kannst, wäre auch eine binäre Serailisierung eine sinnvolle Möglichkeit.
Dann können die Daten direkt als Objekte eingelesen werden.

Wenn dies aber kein JSON/XML ist und du auch keinen Einfluss auf das Format nehmen kannst, kommst du ja um das selber parsen nicht rum.

Was das Offset angeht, könntest du dem den FileStream holen über File.Open und dann per Seek die Position in Bytes angeben.
Dann kannst du diesen FileStream an den StreamReader geben und dieser liest dann die Daten aber dieser Position.
Ob das aber viel hilft kannst nur du prüfen.

Wie groß sind den deine Dateien und wie komplex ist den der Parse Prozess?
Wenn die Dateien klein und schnell geparst sind, dann würde ich hier keinen Aufwand in Offsets oder andere Punkte stecken.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.807 Beiträge seit 2008
vor 5 Jahren

Dachte - da ich auch QuickIO kenne - das es etwas ähnliches für Textdateien gibt 😃

Naja, da vergleichst halt Äpfel mit Birnen.
QuickIO hat einen ganz anderen Fokus und Hintergrund; aufgrund der Funktionsweise des System.IO Namespaces bzgl. dem Iterieren durch Windows File Handles.

Diese Situation gibt es bei Streams gar nicht.

K
Killerkrümel Themenstarter:in
166 Beiträge seit 2008
vor 5 Jahren

Äpfel und Birnen sind trotzdem beides Obstsorten.

Genau wie es bei QuickIO auch möglich ist, ansonsten den StandardIO namespace zu nutzen.
(Obwohl ich das seitdem ich QuickIO kenne nahezu niemandem raten würde)

Dachte lediglich, ihr kennt vielleicht eine Library/Ein Snippet, die mich einen Fileparse by Offset (o.Ä.) (Den mit Sicherheit jemand anders schon mal gemacht hat) nicht neu erfinden lassen muss.

Aber trotzdem Danke für eure Zeit.

C
2.121 Beiträge seit 2010
vor 5 Jahren

Du kannst zumindest nativ eine Datei schon an einer bestimmten Stelle lesen. Was .NET dafür bereitstellt weiß ich nicht auswendig, habs noch nie gebraucht.
Das Problem dabei ist: wo ist die gewünschte Stelle?
Das bringt dir nur dann etwas wenn du weißt wie lang die Zeilen sind die du überspringen willst. Sprich wenn die Zeilen alle gleich lang sind kannst du sagen, jetzt ab der aktuellen Position x Bytes weiterspringen.
Das springen ist auch nur dann sinnvoll wenn du wirklich sehr viel überspringst.

Wenn du das nicht weißt musst du eben die Zeilen einlesen und selber überspringen.

Unter uns, wenn es wirklich nur das überspringen von Zeilen ist wirst dir keine extra Library antun wollen nur um das bisschen Code dazu nicht selbst schreiben zu müssen? Den Rest der Bearbeitung musst du ja sowieso selbst übernehmen.

File.ReadAllLines tut schon das gröbste dabei. Dann hast du eine Ansammlung von Zeilen die du mit einem Index durchlaufen kannst. Den zählst du um 10 weiter wenn du die nächsten 10 Zeilen nicht brauchst. Das war jetzt praktisch schon dein Snippet.

T
2.219 Beiträge seit 2008
vor 5 Jahren

@chilic
Zum überspringen kannst du im Stream per Seek sagen in welche Richtung und wieviele Bytes du springen willst.
Der Stream merkt sich ja seine aktuelle Option, beginnend bei 0.

Damit könnte er einfach sagen er will die Metadaten mit X Bytes überspringen mit Richtung Forward überspringen.
Dies wäre auch die einfachste Lösung die er kriegen kann.

Wenn er es noch einfacher will, müsste er die Daten selbst per (De)Serialisierung speichern und laden.
Dann könnte er diese entweder als XML, JSON oder direkt als Binärdaten speichern und laden.
Noch einfacher ginge es dann nicht mehr.
Setzt aber eben voraus, dass er die Daten selbst schreibt und nicht durch ein externes Tool/Service bereitsgestellt werden!

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

D
152 Beiträge seit 2013
vor 5 Jahren

Ist nur die Frage um wie viel Bytes, solange alle Zeichen die gleiche Anzahl an Bytes (ISO 8859, UTF 16, UTF 32) haben relativ leicht. Aber bei UTF 8 sicherlich blöd, wenn man mitten in einer Bytekette von einen Zeichen springt und dann beginnt zu lesen.

Wenn man die Kodierung kennt, kann man vom Ende ggf. soweit zum Anfang bewegen bis man eine die gewünschte Anzahl an Zeilenumbrüchen zusammen hat.

K
Killerkrümel Themenstarter:in
166 Beiträge seit 2008
vor 5 Jahren

>Interessanter Ansatz. Ich schaue mal was ich finde / schreibe und stelle es bei bedarf hier rein 😃

16.807 Beiträge seit 2008
vor 5 Jahren

Mich würde auch das Aufwand-Nutzen-Verhältnis am Ende interessieren 😃

K
Killerkrümel Themenstarter:in
166 Beiträge seit 2008
vor 5 Jahren

Hallo Abt,

das fühlt sich auch grade nach Premature-Optimization an.^^
Trotzdem danke für euer Feedback.

Viele Grüße, Killerkruemel

D
152 Beiträge seit 2013
vor 5 Jahren

Ich weiß ja nicht wie groß die Dateien am Ende sind. Aber bei wenigen Megabytes sieht es wohl für die Kosten nicht so gut aus.