![]() |
Performancefrage: Anwendung von Append/Writeln/Closefile
Hallo!
Mein Programm beherbergt eine Menge Funktionen, die alle relativ schnell und häufig hintereinander und vor allem durcheinander Zeilen an das Ende eines Textfiles hängen (append und writeln). Nun ist meine Frage ob die Vorgehensweise empfehlenswert ist, jedes Mal das Textfile zu öffnen, um es anschließend sofort wieder zu schließen (wirkt sich das stark aus?). Oder ist es möglich das File zum Starten des Programms zu öffnen und es dann erst beim Beenden des Programms zu schließen?! |
Re: Performancefrage: Anwendung von Append/Writeln/Closefile
Verwende doch eine Stringlist (TStringList F1 in Delphi ;) ). Diese kannst du beim Programmstart laden,
dann die Zeilen bearbeiten und diese am Programmende speichern. Klar ist das herumwirtschaften mit öffnen und schliessen der Datei auf der Festplatte nicht empfelenswert. Logischerweise wird dadurch die Festplatte höher beansprucht. |
Re: Performancefrage: Anwendung von Append/Writeln/Closefile
Allerdings solltest du beachten, dass bei einer TStringlist alle Daten im RAM abgelegt werden. bei großen Dateien kann das zu eienr sehr hohen Speicherauslastung führen.
Was spricht denn dagegen, die File-Variable irgendwo im programm zwischenzuspeichern (z.B. als globale Variable oder besser als privates Feld der Form) und dann immer wieder zu benutzen?
Delphi-Quellcode:
Kann sein, dass hier irgednwo ein Fehler wie z.B. ein falscher Prozedurenname ist, denn ich hab ehrlich gesagt noch nie mit den Pascalfunktionen für Dateien gearbeitet, sondern immer nur mit Streams.
TForm1 = class(TForm)
{...} private FTextFile: textfile; {...} end; // Programmstart: AssignFile(FTextFile,'log.txt'); // "Andauernd aufgerufene" Methode: WriteLn(FTextFile,'Hallo Welt'); // Programmende: CloseFile(FTextFile); |
Re: Performancefrage: Anwendung von Append/Writeln/Closefile
Okay.. Die große Speicherauslastung möchte ich nicht riskieren, deswegen war meine Idee auch das ganze in das Textfile auszulagern. Eine Überlegung war auch dass nicht alles verloren gehen soll wenn das Programm einmal ungeschickt beendet wird und die End-Speicherung daher ausbleibt.
Dass es so funktioniert wie NamenLozer vorgeschlagen hat wusste ich bislang noch nicht.. Aber befinden sich dabei nicht auch alle Daten permanent im RAM?! Gut, man könnte die Daten auch zwischenspeichern wenn sie eine bestimmte Größe überschreiten.. Prinzipiell bin ich für alle Möglichkeiten offen, hauptsache am Ende ist die Datei geschrieben und hat möglichst wenig Performance gekostet.. ;) |
Re: Performancefrage: Anwendung von Append/Writeln/Closefile
[quote="turboPASCAL"Klar ist das herumwirtschaften mit öffnen und schliessen der Datei auf der Festplatte nicht empfelenswert.
Logischerweise wird dadurch die Festplatte höher beansprucht.[/quote] Logischerweise wird die Festplatte nicht notwendigerweise höher beansprucht, da es soetwas wie einen Cache gibt. Das explizite Schließen hat den Vorteil, das Du sicher sein kannst, das Deine Daten auch wirklich gespeichert sind, bei einer Stringlist wäre bei einem Programmabsturz nichts gesichert. Bis auf den Umstand, das die AssignFile/Append/WriteLine/Close-Routinen veraltet sind, sprichts nichts weltbewegendes gegen den Einsatz. Mit wieviel Aufrufen/Schreibvorgängen rechnest Du denn? |
Re: Performancefrage: Anwendung von Append/Writeln/Closefile
Wenn die Routinen veraltet sind, was würde man denn dann heute stattdessen nehmen?!
Geschätz wären es pro Minute bis zu 200 Aufrufe. |
Re: Performancefrage: Anwendung von Append/Writeln/Closefile
...und wie gross ist die zu verwaltende Datenmenge ?
|
Re: Performancefrage: Anwendung von Append/Writeln/Closefile
Erstelle einen separaten Thread, der die Daten im Hintergrund auf die Platte schreibt.
Das moderne Pendant sind überigens Streams, hier wäre es ein TFileStream. Aber wie gesagt, mit AssignFile geht das schon. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 16:47 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz