Große Textdatei - einzelne Zeile löschen

[himitsu]

Zitat:

Was übersehe ich hier?

Daß du zwei Dateien brauchs? (Lesen + Schreiben)

Selbst wenn du vor/nach dem Lesen/Schreiben die Stream-Position "zurück"-setzt,
bekommst du Probleme, wenn die geschriebene Zeile länger ist, als die Gelesene, weil du damit ja bereits die nächste Zeile überschreibst, welche du noch garnicht gelesen hast.

Mit passenden Sharing-Rechten, kann man die gleiche Datei auch mehrmals öffnen, also Lesen und nochmal zum Schreiben.
Aber kann man auch mit nur einem File-Handle und zwei Cursor-Positionen.


Wobei es hier ginge, da Schreiben kürzer ist, als Lesen. (Zeile>'' lesen und Zeile='' schreiben)
Aber nein, SO kannst du keine Zeile löschen, denn die nachfolgenden Zeilen bleiben dennoch an der selben Stelle, was DU selbst verschieben müsstest.
Würdes du die Zeile mit einem '' löschen überschreiben, bliebe der Rest der alten Zeile dennoch erhalten (man könnte diese Zeile höchstsen in der selben Länge z.B. mit mehreren #0 oder ' ' überscheiben, ohne Nachfolgendes verschieben zu müssen)

Code:

** = Zeilenumbruch
_  = Leerzeichen, #0 oder sonstwas

Zeile1**Zeile2**Zeile3**Zeile4** ~ Original

NeueZeile1**e2**Zeile3**Zeile4** ~ Zeile1** durch NeueZeile1** überschrieben (Zeile2** nicht mehr lesbar)
xx**e1**Zeile2**Zeile3**Zeile4** ~ Zeile1** durch xx** überschrieben
**ile1**Zeile2**Zeile3**Zeile4** ~ Zeile1** durch ** überschrieben, aka WriteLn('')

______**Zeile2**Zeile3**Zeile4** ~ Zeile1** durch ______** überschrieben
________Zeile2**Zeile3**Zeile4** ~ Zeile1** durch ________ überschrieben
********Zeile2**Zeile3**Zeile4** ~ Zeile1** durch ******** überschrieben, also 4 Mal WriteLn(''), aber bei ungerader Länge hast'e ein kleines Problem
Zeile2**Zeile3**Zeile4**         ~ Zeile1** gelöscht und Nachfolgendes verschoben (schnell wird es so aber nicht ... weil ja massenhaft Speicher mehrmals verschoben wird)

WriteLn ohne #13#10 heißt Write




TStringList oder TStringStream
und notfalls als 64 Bit kompilieren (ja, neuere Delphis haben ein paar Vorteile)

Auch wenn eine 100M Datei vermutlich ebenfalls in 32 Bit funktioniert.
Man darf aber bedenken, dass der Speicherverbauch beim Laden/Speichern auch mal vorübergehend das 5-fache belegen kann, aber 500M passen ja noch. (5 bei Unicode, aber 2- bis 3-faches auch schon im D7 mit ANSI)




* "nutzlos" zu speichern/überschreiben macht es langsamer
* die alten "Pascal"-Textdatei-Funktionen arbeiten mit einem sehr unoptimalen Buffering = langsam
* TStringList ist nicht ganz optimal und braucht mehr Arbeitsspeicher, aber dennoch ist es viel schneller

* of_insstr sucht und öffnet/speichert immer wieder Dateien = langsam
* * die Dateien (FileHandles) sich zu merken und erst am Ende zu schließen wäre schneller (sind ja nur etwa 60 bis 255 Dateien)
* * oder die QuellDatei mehrmals durchlaufen und jeweils nur EINE "of_insstr"-Datei du behandeln ... zwar mehrmals Lesen aber immer nur jeweils eine Ausgabedatei in einem Rutsch

[Uwe Raabe]

Check doch erstmal, ob das Lesen der Datei der Bottleneck ist oder das Schreiben der Einzeldateien.

[Der schöne Günther]

Ist es schon zu spät für mich, oder machst du bei jeder einzelnen Zeile deine Zieldatei auf und wieder zu?

[jaenicke]

Ich würde hier mit MMFs arbeiten. Durch das Mapping in den Arbeitsspeicher ist das extrem schnell. Damals kam ich bei einer normalen Festplatte auf 84 MiB/s, was heute mit einer SSD noch viel schneller gehen sollte.

Ich habe dafür einen Wrapper geschrieben:
https://www.delphipraxis.net/151898-...ei-reader.html

Flamefire hat sich das angeschaut und das ganze mit Streams umgesetzt:
https://entwickler-ecke.de/viewtopic.php?t=100088

Für die beste Performance musst du da vielleicht noch ein wenig schrauben, aber zumindest siehst du dort wie du mit MMFs arbeiten kannst.

[Monday]

Kannst du mal bei Notepad++ das Plugin "BigFiles - Open Very Large Files" probieren? Würde mich interessieren, ob er das packt.

[dummzeuch]

Ich hatte mal ein Tool zum Anschauen großer Textdateien geschrieben, das ich damals mit einem Dump der Wikipedia getestet hatte (damals 48 GB).

Funktionsweise war, dass es in einem Hintergrund-Thread die Datei liest und einen Index der Zeilenumbrüche bzw. Zeilenanfänge erzeugt, den es in eine Datei schreibt, so dass der Index nicht jedes Mal neu erzeugt werden muss.

Vielleicht findest Du ja im Sourcecode ein paar Anregungen?

Wichtig: Die Suchfunktion habe ich nie fertiggestellt, nicht dass Du dich wunderst, dass sie nicht funktioniert.