Handling von großen ASCII-Files

Für allgemeine Fragen zur Programmierung, welche nicht! direkt mit Lazarus zu tun haben.

Handling von großen ASCII-Files

Beitragvon photor » 16. Aug 2017, 15:35 Handling von großen ASCII-Files

Hallo Forum,

ich brauche ein paar Anregungen zu folgendem Problem:
  • Es gibt (seit langem) ein Delphi-Programm in der Firma, das genutzt wird, um FEM-Ergebnisse weiter zu verarbeiten. Die Ergebnisdateien sind groß (bis zu mehreren GB) und es müssen Daten aus mehreren gleichzeitig verarbeitet werden. Das Handling ist momentan eher weniger optimal (es wird mehr Zeit mit dem Lesen der Daten als mit deren Verarbeitung vertan). Ich versuche das nun zu verbessern (es gibt mittlerweile ja größere, schnellere Rechner :) ).
  • Die Files sind ASCII-Files und bestehen aus verschiedenen Sektionen unterschiedlicher Größe und Aufbau (das wird "Postcode" genannt), so dass man irgendwie durch das ganze File durch muss, um die Daten (Postcodes) zusammenzutragen; meine Idee, diese Sektionen zu identifizieren, einzulesen und die Daten gleich in entsprechende Strukturen zu speichern (es werden nicht alle Sektionen gebracht).
  • Für meine Versuche in Lazarus (zuhause) habe ich erstmal platterweise so ein File als ganzes in eine TStringList eingelesen; ein solches File passte auch problemlos in meinen (Linux-)Rechner. Die TStringList konnte man dann recht einfach mittels Index durchlaufen und auswerten. Das funktioniert unter Delphi/Windows leider nicht ("not enough memory" wohl weil noch 32-bit-ig(*)) beim sl:=StringList.Create; sl.LoadFromFile(..);.
  • Deshalb versuche ich, die Files mittels TFileStream zu lesen, was prinzipiell funktioniert; ich kann das File Zeile für Zeile einlesen und diese dann weiterverarbeiten: erstmal nur nach den Postcodes suchen. Soweit funktioniert es.
  • Wenn ein Postcode gefunden ist, der ausgewertet werden soll, würde ich gerne eine Funktion damit beauftragen. Hier die Frage: kann ich den Stream an die Funktion weitergeben, so dass die dort weiter parsen kann? Und kann ich die Position im Stream am Ende zurück geben, so dass ich weiter suchen kann und von dort die nächste Postcode-Auswerteroutine aufrufen kann? Ich möchte vermeiden, jedesmal den Stream neu zu öffnen und wieder von vorne zu beginnen.
  • Gibt es noch andere Herangehensweisen? Stichworte zum Nachlesen reichen.
Wie immer, sehr dankbar für jede Anregung,

Photor

PS: wenn Codeschnipsel gewünscht werden, kann ich was extrahieren und anpassen.

(*) Umstellung auf 64 Bit wird sicher auch irgendwann kommen, ist aber für den Moment eine zu große Baustelle.
photor
 
Beiträge: 146
Registriert: 24. Jan 2011, 21:38
OS, Lazarus, FPC: Arch Linux (L 1.6.4 FPC 3.0.2) | 
CPU-Target: 64Bit
Nach oben

Beitragvon Mathias » 16. Aug 2017, 16:09 Re: Handling von großen ASCII-Files

Das funktioniert unter Delphi/Windows leider nicht ("not enough memory" wohl weil noch 32-bit-ig(*)) beim sl:=StringList.Create; sl.LoadFromFile(..);.

Da sagst es, bei 32Bit ist bei 4GByte fertig. Da es unter Linux läuft, hast du sehr grosse Chance, das ist mit dem 64Bit Lazarus auch unter Windows geht. Vor aus gesetzt, du hast ein 64Bit Windows.

Es gibt (seit langem) ein Delphi-Programm in der Firma, das genutzt wird, um FEM-Ergebnisse weiter zu verarbeiten. Die Ergebnisdateien sind groß (bis zu mehreren GB) und es müssen Daten aus mehreren gleichzeitig verarbeitet werden. Das Handling ist momentan eher weniger optimal (es wird mehr Zeit mit dem Lesen der Daten als mit deren Verarbeitung vertan). Ich versuche das nun zu verbessern (es gibt mittlerweile ja größere, schnellere Rechner :) ).
Ein Binär-Format wäre für diesen Zweck wohl besser gewesen. Oder man verwendet mehrere kleinere Dateien, aber das Ganz ist wohl recht schwierig, wen man etwas bestehendes ändern will. :wink:
Mit Lazarus sehe ich gün
Mit Java und C/C++ sehe ich rot
Mathias
 
Beiträge: 3262
Registriert: 2. Jan 2014, 17:21
Wohnort: Schweiz
OS, Lazarus, FPC: Linux (die neusten Trunc) | 
CPU-Target: 64Bit
Nach oben

Beitragvon wp_xyz » 16. Aug 2017, 16:47 Re: Handling von großen ASCII-Files

photor hat geschrieben:Wenn ein Postcode gefunden ist, der ausgewertet werden soll, würde ich gerne eine Funktion damit beauftragen. Hier die Frage: kann ich den Stream an die Funktion weitergeben, so dass die dort weiter parsen kann?

Natürlich. Etwa so:
Code: Alles auswählen
function FindPostCode(AStream: TStream; APostCode: String): Int64;  

photor hat geschrieben:Und kann ich die Position im Stream am Ende zurück geben, so dass ich weiter suchen kann und von dort die nächste Postcode-Auswerteroutine aufrufen kann? Ich möchte vermeiden, jedesmal den Stream neu zu öffnen und wieder von vorne zu beginnen.

Ebenfalls natürlich. Verwende die les-/schreibbare Eigenchaft "Position" des Streams. Achtung: Position wird mit jeder Schreib/Leseaktion automatisch weitergerückt.

Code: Alles auswählen
var
  w: Word;
begin
  AStream.Position := 1000;   // Setze den Stream auf "Index" 1000;
  w := AStream.ReadWord,      // Lese zwei Byte --> Position steht auf 1002

Ein Tipp noch: Einen mehrere GB großen Filestream Byte für Byte einzulesen wird ganz schön lang dauern. Ein MemoryStream scheidet aus, weil dann die Datei komplett in Speicher liegt. Nimm einen gepufferten Stream, etwa TBufStream, der allerdings, wenn ich mich nicht täusche, nur vorwärts laufen kann. Oder nimm den gleichnamigen aus fpspreadsheet, der kann vorwärts/rückwärts laufen; die Unit fpsstreams ist autark und kann ohne den Rest des Package verwendet werden (https://sourceforge.net/p/lazarus-ccr/s ... treams.pas). So ein gepufferter Stream liest die Datei häppchenweise ein (der von fpspreadsheet nimmt 1MB-Blöcke), so dass man auf diesem Dateistück im Speicher arbeitet; wenn der eingelesene Bereich überschritten wird, dann wird automatisch der nächste Block nachgeladen.

Dann noch: Als Laufvariable im Stream Int64 verwenden, mit Integer stößt du bei 2GB an die Grenzen.

photor hat geschrieben:Gibt es noch andere Herangehensweisen? Stichworte zum Nachlesen reichen.

Es gibt noch Memory-Mapped-Files. Da greift man auf Dateien so zu, als wären sie im Speicher, obwohl sie nicht im klassichen Sinn eingelesen wurden. Dazu gab es vor kurzem einen Beitrag im englischen Forum, wo auch so ein Stream vorgestellt worden ist, allerdings nur für Windows, wenn mich nicht alles täuscht (http://forum.lazarus.freepascal.org/ind ... #msg254956).
wp_xyz
 
Beiträge: 2281
Registriert: 8. Apr 2011, 08:01

Beitragvon photor » 17. Aug 2017, 16:48 Re: Handling von großen ASCII-Files

Mathias hat geschrieben:Da sagst es, bei 32Bit ist bei 4GByte fertig. Da es unter Linux läuft, hast du sehr grosse Chance, das ist mit dem 64Bit Lazarus auch unter Windows geht. Vor aus gesetzt, du hast ein 64Bit Windows.

Das File selbst war nur ca. 1.7 GB groß. Aber als StringList wird es wohl größer. Egal; weil irgendwann werden Files größer(*) => 32-bit ist auf Dauer keine Lösung (aber muss es zunächst bleiben wg. Zeitmangel).
Das File als ganzes in den Speicher zu laden, habe ich aufgegeben (zumal ich für die Auswertung üblicherweise Daten aus 7 und mehr solcher Files brauche - FEM bedeutet: Datenmassen bewältigen).
Allerdings ist die Umstellung auf 64-bit nicht so einfach: ein (naiver) Versuch endete mit Zusammen-klappen des Programms - irgendwo wird noch eine 32-bit-Komponente verwendet, denke ich. Aber da gibt es leider noch viiieeele andere Baustellen ...
In der Firma steht ein Delphi zur Verfügung (64-bit-Windows); Lazarus ist nur zuhause mein Testfeld.

Mathias hat geschrieben:Ein Binär-Format wäre für diesen Zweck wohl besser gewesen. Oder man verwendet mehrere kleinere Dateien, aber das Ganz ist wohl recht schwierig, wen man etwas bestehendes ändern will. :wink:

Ja. Und - Das Format ist vom FEM-Programm (kommerzielles Programmpaket) vorgegeben. Zur Eherenrettung: die bieten natürlich ein Binärformat an. Da sind die Files kleiner, aber die Daten da raus zu klauben ist bestimmt um etliches schwerer (SCHÜTTELFROSTANFALL).

Ciao,
Photor

(*)zumal noch andere Beschränkungen zuschlagen können: Stack-Größe fällt mir als erstes ein.
photor
 
Beiträge: 146
Registriert: 24. Jan 2011, 21:38
OS, Lazarus, FPC: Arch Linux (L 1.6.4 FPC 3.0.2) | 
CPU-Target: 64Bit
Nach oben

Beitragvon Timm Thaler » 17. Aug 2017, 19:03 Re: Handling von großen ASCII-Files

Als erstes: Datenreduktion.

Kannst Du die Dateien umkopieren und dabei nicht relevante Daten weglassen?

Als zweites: Virtuelle Disk.

Unter Linux hab ich ein virtuelles Verzeichnis eingerichtet, in dem Dateien temporär abgelegt werden. Der Zugriff darauf ist natürlich erheblich schneller.

Erfordert allerdings entsprechenden RAM, unter 16GB braucht man da wahrscheinlich nicht anfangen. Wo wir wieder beim 64bit-System wären.
Timm Thaler
 
Beiträge: 439
Registriert: 20. Mär 2016, 22:14
OS, Lazarus, FPC: Win7-64bit Laz1.6 FPC3.0.0, Raspbian Jessie Laz1.6 FPC3.0.0 | 
CPU-Target: Raspberry Pi 3
Nach oben

Beitragvon photor » 17. Aug 2017, 19:35 Re: Handling von großen ASCII-Files

Timm Thaler hat geschrieben:Als erstes: Datenreduktion.
Kannst Du die Dateien umkopieren und dabei nicht relevante Daten weglassen?

Das versuche ich gerade: einmal durchscannen muss ich die Dateien dafür aber erstmal: Postcodes finden, die ich brauche, andere weglassen, einige können reduziert werden (dann müssen andere angepasst werden). Eine komplexe Materie.

Timm Thaler hat geschrieben:Als zweites: Virtuelle Disk.
[...]
Erfordert allerdings entsprechenden RAM, unter 16GB braucht man da wahrscheinlich nicht anfangen. Wo wir wieder beim 64bit-System wären.

Das Arbeitssystem ist groß genug (128 GB, Windows). Da wäre was in diese Richtung möglich: Aber das wird von der IT wohl nicht eingerichtet werden (müsste sich an- und abschalten lassen, da andere Programme massiv im RAM arbeiten).

Ich sehe in der Überarbeitung des File-Handling eher Potenzial; das packt das Problem an der Wurzel.

Ciao,
Photor
photor
 
Beiträge: 146
Registriert: 24. Jan 2011, 21:38
OS, Lazarus, FPC: Arch Linux (L 1.6.4 FPC 3.0.2) | 
CPU-Target: 64Bit
Nach oben

Beitragvon photor » 17. Aug 2017, 19:47 Re: Handling von großen ASCII-Files

Hallo wp_xyz,

(sorry, hätte Dich fast vergessen)

wp_xyz hat geschrieben:
photor hat geschrieben:kann ich den Stream an die Funktion weitergeben, so dass die dort weiter parsen kann?

Natürlich. Etwa so:
Code: Alles auswählen
function FindPostCode(AStream: TStream; APostCode: String): Int64;  



wp_xyz hat geschrieben:
photor hat geschrieben:Und kann ich die Position im Stream am Ende zurück geben

Ebenfalls natürlich. Verwende die les-/schreibbare Eigenchaft "Position" des Streams. Achtung: Position wird mit jeder Schreib/Leseaktion automatisch weitergerückt.
Code: Alles auswählen
var
  w: Word;
begin
  AStream.Position := 1000;   // Setze den Stream auf "Index" 1000;
  w := AStream.ReadWord,      // Lese zwei Byte --> Position steht auf 1002

Ich habe das erstmal mit dem TFileStream gelöst. Der ist Unit-weit global, und die Funktion, die jeweils einen Postcode einliest (zeilenweise mittels str:=fl.ReadLine, die Anzahl der eingelesen Zeilen zurück gibt.

wp_xyz hat geschrieben:Ein Tipp noch: Einen mehrere GB großen Filestream Byte für Byte einzulesen wird ganz schön lang dauern. Ein MemoryStream scheidet aus, weil dann die Datei komplett in Speicher liegt. Nimm einen gepufferten Stream, etwa TBufStream, der allerdings, wenn ich mich nicht täusche, nur vorwärts laufen kann. Oder nimm den gleichnamigen aus fpspreadsheet, der kann vorwärts/rückwärts laufen; die Unit fpsstreams ist autark und kann ohne den Rest des Package verwendet werden (https://sourceforge.net/p/lazarus-ccr/s ... treams.pas). So ein gepufferter Stream liest die Datei häppchenweise ein (der von fpspreadsheet nimmt 1MB-Blöcke), so dass man auf diesem Dateistück im Speicher arbeitet; wenn der eingelesene Bereich überschritten wird, dann wird automatisch der nächste Block nachgeladen.


wp_xyz hat geschrieben:Dann noch: Als Laufvariable im Stream Int64 verwenden, mit Integer stößt du bei 2GB an die Grenzen.

Guter Hinweis. Das werde ich beherzigen (obwohl ich momentan Zeile zähle).

wp_xyz hat geschrieben:
photor hat geschrieben:Gibt es noch andere Herangehensweisen? Stichworte zum Nachlesen reichen.

Es gibt noch Memory-Mapped-Files. Da greift man auf Dateien so zu, als wären sie im Speicher, obwohl sie nicht im klassichen Sinn eingelesen wurden. Dazu gab es vor kurzem einen Beitrag im englischen Forum, wo auch so ein Stream vorgestellt worden ist, allerdings nur für Windows, wenn mich nicht alles täuscht (http://forum.lazarus.freepascal.org/ind ... #msg254956).

Den Link (und den oben) schau ich mir an.

Danke für die Tipps,
Photor
photor
 
Beiträge: 146
Registriert: 24. Jan 2011, 21:38
OS, Lazarus, FPC: Arch Linux (L 1.6.4 FPC 3.0.2) | 
CPU-Target: 64Bit
Nach oben

Beitragvon wp_xyz » 17. Aug 2017, 21:03 Re: Handling von großen ASCII-Files

photor hat geschrieben:Ich habe das erstmal mit dem TFileStream gelöst. Der ist Unit-weit global, und die Funktion, die jeweils einen Postcode einliest (zeilenweise mittels str:=fl.ReadLine, die Anzahl der eingelesen Zeilen zurück gibt.

Keine Ahnung, was du damit meinst. Der übliche TFilestream, so wie er in der Unit Classes implementiert ist, hat jedenfalls keine Methode Readline.
wp_xyz
 
Beiträge: 2281
Registriert: 8. Apr 2011, 08:01

Beitragvon braunbär » 17. Aug 2017, 22:07 Re: Handling von großen ASCII-Files

Hast du schon daran gedacht, in einem ersten Schritt deine Dateien in irgend ein vernünftiges SQL Datenbankformat zu konvertieren (Firebird, MySQL, SQLite, was auch immer)?
Das sollte nicht allzu aufwändig sein, und danach kannst du die Daten dank der Indexierungsmöglicheiten einer Datenbank sehr effizient selektieren und bearbeiten.
braunbär
 
Beiträge: 164
Registriert: 8. Jun 2017, 17:21

Beitragvon creed steiger » 17. Aug 2017, 22:29 Re: Handling von großen ASCII-Files

An eine Ramdisk hätte ich als erstes gedacht .. das könnte doch einiges an Geschwindigkeit bringen.
ansonsten das was wp_xyz vorschlägt
creed steiger
 
Beiträge: 937
Registriert: 11. Sep 2006, 21:56

Beitragvon photor » 18. Aug 2017, 16:44 Re: Handling von großen ASCII-Files

wp_xyz hat geschrieben:
photor hat geschrieben:Ich habe das erstmal mit dem TFileStream gelöst. Der ist Unit-weit global, und die Funktion, die jeweils einen Postcode einliest (zeilenweise mittels str:=fl.ReadLine, die Anzahl der eingelesen Zeilen zurück gibt.

Keine Ahnung, was du damit meinst. Der übliche TFilestream, so wie er in der Unit Classes implementiert ist, hat jedenfalls keine Methode Readline.


Oh. Da hast Du recht; ich war ungenau und war inzwischen beim TStreamReader gelandet; dort gibt es die Methode ReadLine:
Code: Alles auswählen
 
slT19File := TStreamReader.Create(FileName);
while not(slT19File.EndOfStream) do
  begin
    str := slT19File.ReadLine;
    inc(nl);
...
  end;
end;
 

Die Variable nl zählt einfach die gelesenen Zeilen hoch. Momentan gehe ich einfach nur linear durch das File und sammle die Daten. Ob ich die dann (gefiltert und reduziert) wieder in ein anderes File rausschreibe, hangt auch davon ab, ob und wieviel ich im Speicher halten kann (jedes File etwa 1.7 GB; im konkreten Fall brauche ich 18 solcher Files).

Ciao,
Photor
photor
 
Beiträge: 146
Registriert: 24. Jan 2011, 21:38
OS, Lazarus, FPC: Arch Linux (L 1.6.4 FPC 3.0.2) | 
CPU-Target: 64Bit
Nach oben

• Themenende •

Zurück zu Programmierung



Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

porpoises-institution
accuracy-worried