Ini-Inhalt geht in sehr seltenen Fällen verloren (TMemIniFile)

[nahpets]

Zitat:

Zitat von CodeX (Beitrag 1326675)

Zitat:

Zitat von Uwe Raabe (Beitrag 1326641)

Zitat:

Zitat von nahpets (Beitrag 1326638)

hatte nur den Eindruck, dass Dein Vorschlag nicht so ganz vorstanden worden ist, und dahinter ein deutlich komplexerer Lösungsansatz vermutet wurde.

Den Eindruck habe ich mittlerweile aber auch...

Hm, sind meine Bedenken wirklich so daneben? Immerhin versuche ich hier ein Problem zu lösen, das eigentlich gar nicht auftreten dürfte, es aber wohl aufgrund ganz blöder Umstände doch tun kann. Der Vorschlag mit dem Umbenennen beinhaltet aber ja wiederum einen für mich intransparenten Zustand: Was passiert während des Umbenennens? Wenn dieser Befehl intern aus mehreren Teilschritten besteht und der Prozess genau dazwischen Abbricht, kann die Datei dann ja auch wieder verloren gehen. Ich sage nicht dass das so ist, aber zumindest sehe ich hier eine (für mich) Unbekannte.

Nein, Deine Bedenken sind selbstverständlich nicht daneben, aber die Sicherheit, die Du (vermutlich) anstrebst, wirst Du nicht erlangen.

Egal was Du in Deinem Programm machst:
Es ist immer möglich, dass zwischen zwei Programmschritten, die immer korrekt verlaufen, irgendwann doch mal der Strom weg ist, ein Hardwaredefekt auftritt, der Anwender einen Prozess abschießt...

Daher ja mein Vorschlag, immer wenn was wichtiges in der INI geändert wurde, UpdateFile aufzurufen.

Oder halt eine Routine implementieren, die Dir mehrere Sicherungeskopieen der Ini-Datei erstellen.

Dir scheint die Korrektheit und Speicherung der INI-Datei ja sehr wichtig zu sein. Beschreibe doch einfach mal kurz, warum, in welchem Umfeld...

Eventuell wird es für uns verständlicher, Deine Sorgen zu teilen und eventuell einen anderen Lösungsansatz zur Problemlösung zu finden.

Welche Datenmengen stehen in der INI-Datei?

Könnte eine Embedded-Firebird-Datenbank oder eine SQLite-Datenbank... oder sowas helfen?
Da sind die Daten in 'ner Transaktion per Commit weggeschrieben und der Stand ist dann beim nächsten Programmstart vorhanden, eine Datenbankdatei ist nicht bei 'nem misslungenen Update leer oder wird vor dem Schreiben gelöscht und dann neu erstellt.

Unter Delphi 7 sieht UpdateFile so aus:

Delphi-Quellcode:

procedure TMemIniFile.UpdateFile;
var
  List: TStringList;
begin
  List := TStringList.Create;
  try
    GetStrings(List);
    List.SaveToFile(FFileName);
  finally
    List.Free;
  end;
end;

In einer Ableitung könnte man das ja dahingehend überschreiben, dass man nach dem SaveToFile noch prüft, ob die Datei auch wirklich erstellt wurde und nicht leer ist.
Man könnte sie auch anschließend in eine zweite Stringliste laden und die beiden Stringlisten vergleichen...

Delphi-Quellcode:

procedure TMemIniFile.UpdateFile;
var
  List: TStringList;
  List2: TStringList;
begin
  List := TStringList.Create;
  List2 := TStringList.Create;
  try
    try
      // Hier eventuell die in früherem Post vorgeschlagene "Historisierung" älterer INI-Dateien einbauen...
      GetStrings(List);
      List.SaveToFile(FFileName);
      List2.LoadFromFile(FFileName);
      if List.Text <> List2.Text then begin
        MessageDLG('Abweichung zwischen vor und nach dem Speichern der INI-Datei.',mtError,[mbOk],0);    
      end;     
    except
      on e : Exception do begin
        // Irgendwelche Sicherungsmaßnahmen...
        MessageDLG(e.Message,mtError,[mbOk],0);    
      end;
    end;
  finally
    List2.Free;
    List.Free;
  end;
end;

(Das ist jetzt nur mal so "hingedaddelt" und nicht getestet.)

Schau Dir bitte in den Delphi-Quellen mal GetStrings von TMemIniFile an, könnte da (bedingt durch die verwendeten Daten) eventuell ein Fehler auftreten?

[Sir Rufo]

Mein Vorschlag wäre:

Delphi-Quellcode:

unit System.IniFilesEx;

interface

uses
  System.IniFiles,
  System.SysUtils;

type
  TSafeMemIniFile = class( TMemIniFile )
  private const
    ExtOldData  = '.bak';
    ExtOldEmpty = '.ebak';
  private
    FSaveOnDestroy: Boolean;
    procedure RestoreFileState( const FileName: string );
    procedure DeleteFileIfExists( const FileName: string );
    function GetOldFileName: string;
    function GetEmptyFileName: string;
  protected
    property OldFileName  : string read GetOldFileName;
    property EmptyFileName: string read GetEmptyFileName;
  public
    constructor Create( const FileName: string ); overload;
    constructor Create( const FileName: string; const Encoding: TEncoding ); overload;
    destructor Destroy; override;

    procedure UpdateFile; override;

    property SaveOnDestroy: Boolean read FSaveOnDestroy write FSaveOnDestroy default true;
  end;

implementation

uses
  System.Classes,
  System.IOUtils;

{ TSafeMemIniFile }

constructor TSafeMemIniFile.Create( const FileName: string );
begin
  RestoreFileState( FileName );
  inherited Create( FileName );
  FSaveOnDestroy := true;
end;

constructor TSafeMemIniFile.Create( const FileName: string;
  const Encoding: TEncoding );
begin
  RestoreFileState( FileName );
  inherited Create( FileName, Encoding );
  FSaveOnDestroy := true;
end;

procedure TSafeMemIniFile.DeleteFileIfExists( const FileName: string );
begin
  if TFile.Exists( FileName )
  then
    TFile.Delete( FileName );
end;

destructor TSafeMemIniFile.Destroy;
begin
  if SaveOnDestroy
  then
    UpdateFile( );
  inherited;
end;

function TSafeMemIniFile.GetEmptyFileName: string;
begin
  Result := FileName + ExtOldEmpty;
end;

function TSafeMemIniFile.GetOldFileName: string;
begin
  Result := FileName + ExtOldData;
end;

procedure TSafeMemIniFile.RestoreFileState( const FileName: string );
begin
  if TFile.Exists( OldFileName ) or TFile.Exists( EmptyFileName )
  then
    begin
      DeleteFileIfExists( FileName );

      if TFile.Exists( OldFileName )
      then
        TFile.Move( OldFileName, FileName );

      DeleteFileIfExists( EmptyFileName );
    end;
end;

procedure TSafeMemIniFile.UpdateFile;
begin
  RestoreFileState( FileName );

  if TFile.Exists( FileName )
  then
    TFile.Move( FileName, OldFileName )
  else
    TFile.WriteAllText( EmptyFileName, '' );

  inherited;

  DeleteFileIfExists( OldFileName );
  DeleteFileIfExists( EmptyFileName );
end;

end.

[CodeX]

Ich habe jetzt mal die Geschwindigkeit von TMemIniFile beim Schreiben überprüft.
Getestet habe ich in verschiedenen Konstellationen, aber nachfolgend beispielhaft eine Variante mit Schreiben von 1000 Werten, die jeweils aus 30 zufälligen Zeichen bestehen.

Delphi-Quellcode:

var
  ini : TMemIniFile;
  i : Integer;
  LogDateStart : TDateTime;
begin
  LogDateStart := Now;
  
  ini := TMemIniFile.Create(txtFileName.Text);
  try
    for i := 0 to rbgValues.Tag-1 do
      ini.WriteString(txtSection.Text+IntToStr(i), txtIdent.Text+IntToStr(i), RandomPassword(30));
    ini.UpdateFile;
  finally
    ini.Free;
  end;

  memLog.Lines.Add('MEM (' + IntToStr(rbgValues.Tag) +'): '+FormatDateTime('ss:zzz',LogDateStart-Now)+'sec');

Code:

-> In der Ausgangslage ist keine Ini-Datei vorhanden
MEM (1000): 00:163sec
MEM (1000): 00:035sec
MEM (1000): 00:024sec
MEM (1000): 00:033sec
-> Hier Ini-Datei gelöscht
MEM (1000): 00:161sec
MEM (1000): 00:023sec
MEM (1000): 00:015sec
MEM (1000): 00:021sec

Dass noch andere Faktoren hineinspielen, die sich auf die Dauer bei der Genauigkeit auswirken, ist natürlich klar. Aber dass der Speichervorgang ohne Ini ein vielfaches länger dauert als mit vorhandener Datei, ist meiner Meinung nach doch sehr bezeichnend.

[Sir Rufo]

Du hast jetzt erfolgreich gemessen, wie lange das Dateisystem benötigt den Dateinamen einzutragen und den Speicherplatz zu finden.

War das nicht auch zu erwarten?

Und je voller die Platte, desto länger dauert das (mit dem Speicherplatz finden)

[CodeX]

Zitat:

Zitat von Sir Rufo (Beitrag 1326690)

War das nicht auch zu erwarten?

Laut Uwe Raabe, nahpets, etc. soll die Variante mit "Backup löschen, Ini verschieben/umbenennen, Ini erzeugen" performanter sein als bei UpdateFile 2xSaveToFile aufzurufen (siehe mein Vorschlag). Ich habe hier nur den dritten Teil davon gemessen. Die anderen beiden Operationen kommen ja noch dazu.
Frag also nicht mich. ;)

[Luckie]

Warum implementierst du nicht einfach mal Uwes Vorschlag und guckst, was passiert?

Wie helfen dir diese Performancemessungen bei der Lösung deines Problems? Murphy kann immer an einer Stelle deines Programmes zu schlagen, wo es schief geht. Mitten im Umbennnen der Ini-Datei, Strom weg, Bämm. Wobei Murphy das sehr gut timen müsse. Das umbenennen dauert ja nur Millisekunden.

[Uwe Raabe]

Zitat:

Zitat von CodeX (Beitrag 1326689)

Ich habe jetzt mal die Geschwindigkeit von TMemIniFile beim Schreiben überprüft.

Nicht wirklich! Du prüfst die Geschwindigkeit deiner Code-Sequenz, die im Wesentlichen wohl durch die 1000 Aufrufe von RandomPassword und das Anlegen der internen Struktur für TMemInifile beeinflusst wird wird, mit einer Messmethode, die auf ca. 1/18 Sekunde genau auflöst. Du kannst das gerne mal ausprobieren, in dem du die das UpdateFile weglässt und den Rest mal mit und ohne vorhandener INI-Datei vergleichst. Die Werte werden sicher ähnlich sein.

Das reine UpdateFile (1000 Sections mit je einem Eintrag -> ca. 30KB) dauert auf meinem System ca. 6,8 ms(!) - egal, ob die Datei vorher existiert oder nicht. Mit meinem Vorschlag erhöht sich das auf ca. 7.3 ms. Erhöht man die Zahl der Sections auf 10000 (ca. 300KB) bekomme ich Zeiten von 7.4 und 7.8 ms, wobei man hier mit umgebungsbedingten Toleranzen von +/- 0.5 ms rechnen muss.

Delphi-Quellcode:

program Project53;

{$APPTYPE CONSOLE}

uses
  System.SysUtils,
  System.Diagnostics,
  System.IniFiles,
  System.IOUtils;

const
  cFileName = 'C:\TEMP\MyIni.ini';
  cLineCount = 1000;

type
  TMyInifile = class(TMemIniFile)
  private
    FBackupName: string;
  public
    constructor Create(const AFileName: string);
    procedure UpdateFile; override;
    property BackupName: string read FBackupName;
  end;

constructor TMyInifile.Create(const AFileName: string);
begin
  FBackupName := TPath.ChangeExtension(AFileName, '.bak');
  if TFile.Exists(BackupName) then begin
    { eventuell noch weitere Überprüfungen }
    if TFile.Exists(AFileName) then begin
      TFile.Delete(BackupName);
    end
    else begin
      TFile.Move(BackupName, AFileName);
    end;
  end;
  inherited;
end;

procedure TMyInifile.UpdateFile;
begin
  if TFile.Exists(FileName) then begin
    if TFile.Exists(BackupName) then begin
      TFile.Delete(BackupName);
    end;
    TFile.Move(FileName, BackupName);
  end;
  inherited;
end;

type
  TMemIniFileHelper = class helper for TMemIniFile
  public
    procedure Test;
  end;

procedure TMemIniFileHelper.Test;
var
  deltaTime: Int64;
  i: Integer;
  ini: TMemIniFile;
  sw: TStopWatch;
  N: Integer;
  S: string;
begin
  for I := 0 to cLineCount - 1 do begin
    S := IntToStr(i);
    WriteString('Section' + S, 'Ident' + S, S);
  end;

  sw := TStopWatch.StartNew;
  for N := 1 to 100 do begin
    UpdateFile;
  end;
  sw.Stop;
  Writeln('Runtime [', ClassName, ']: ', sw.ElapsedMilliseconds/100:1:3, ' ms');
end;

procedure Main;
var
  ini: TMemIniFile;
begin
  ini := TMemIniFile.Create(cFileName);
  try
    ini.Test;
  finally
    ini.Free;
  end;

  ini := TMyIniFile.Create(cFileName);
  try
    ini.Test;
  finally
    ini.Free;
  end;
end;

begin
  try
    Main;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  Readln;
end.

[Uwe Raabe]

Hier nochmal eine Version, die auch die Alternative mit dem zweifachen Speichern berücksichtigt. Die Laufzeiten sind erwartungsgemäß etwa doppelt so lang wie bei einem originalen TMemIniFile.

Delphi-Quellcode:

program Project53;

{$APPTYPE CONSOLE}

uses
  System.SysUtils,
  System.Diagnostics,
  System.IniFiles,
  System.IOUtils,
  System.Classes;

const
  cFileName = 'C:\TEMP\MyIni.ini';
  cLineCount = 1000;

type
  TSaveMemIniFile = class(TMemIniFile)
  private
    FBackupName: string;
  public
    constructor Create(const AFileName: string);
    property BackupName: string read FBackupName;
  end;

  TSaveMemIniFileRename = class(TSaveMemIniFile)
  private
  public
    procedure UpdateFile; override;
  end;

  TSaveMyIniFileDoubleWrite = class(TSaveMemIniFile)
  public
    procedure UpdateFile; override;
  end;

constructor TSaveMemIniFile.Create(const AFileName: string);
begin
  FBackupName := TPath.ChangeExtension(AFileName, '.bak');
  if TFile.Exists(BackupName) then begin
    { eventuell noch weitere Überprüfungen }
    if TFile.Exists(AFileName) then begin
      TFile.Delete(BackupName);
    end
    else begin
      TFile.Move(BackupName, AFileName);
    end;
  end;
  inherited;
end;

procedure TSaveMemIniFileRename.UpdateFile;
begin
  if TFile.Exists(FileName) then begin
    if TFile.Exists(BackupName) then begin
      TFile.Delete(BackupName);
    end;
    TFile.Move(FileName, BackupName);
  end;
  inherited;
  { Hier könnte man die INI-Datei überprüfen und im Erfolgsfall die Backup-Datei löschen,
    aber das würde eh im Create oder nächsten UpdateFile gemacht. }
end;

procedure TSaveMyIniFileDoubleWrite.UpdateFile;
var
  List: TStringList;
begin
  List := TStringList.Create;
  try
    GetStrings(List);
    List.SaveToFile(BackupName, Encoding);
  finally
    List.Free;
  end;
  inherited;
end;

type
  TMemIniFileHelper = class helper for TMemIniFile
  public
    procedure Test;
  end;

procedure TMemIniFileHelper.Test;
var
  deltaTime: Int64;
  i: Integer;
  ini: TMemIniFile;
  sw: TStopWatch;
  N: Integer;
  S: string;
begin
  for I := 0 to cLineCount - 1 do begin
    S := IntToStr(i);
    WriteString('Section' + S, 'Ident' + S, S);
  end;

  sw := TStopWatch.StartNew;
  for N := 1 to 100 do begin
    UpdateFile;
  end;
  sw.Stop;
  Writeln('Runtime [', ClassName, ']: ', sw.ElapsedMilliseconds/100:1:3, ' ms');
end;

procedure Main;
var
  ini: TMemIniFile;
begin
  ini := TMemIniFile.Create(cFileName);
  try
    ini.Test;
  finally
    ini.Free;
  end;

  ini := TSaveMemIniFileRename.Create(cFileName);
  try
    ini.Test;
  finally
    ini.Free;
  end;

  ini := TSaveMyIniFileDoubleWrite.Create(cFileName);
  try
    ini.Test;
  finally
    ini.Free;
  end;
end;

begin
  try
    Main;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  Readln;
end.

[himitsu]

Jemand auch an das FLUSH beim Schreiben gedacht?
Tipp: TStringList -> TFileStream -> FlushFileBuffers

(man könnte auch direkt NonBuffered schreiben, aber so geht es einfacher)

[nahpets]

Ehrlich gesagt finde ich die Diskussion über die Geschwindigkeit langsam absurd:

Wenn es um's Messen der Schreibgeschwindigkeit geht, dann bitte auch nur das Schreiben messen:

Delphi-Quellcode:

var
  ini : TMemIniFile;
  i : Integer;
  dtStart : TDateTime;
  dtEnde  : TDateTime;
begin
  ini := TMemIniFile.Create(txtFileName.Text);
  try
    for i := 0 to rbgValues.Tag-1 do
     ini.WriteString(txtSection.Text+IntToStr(i), txtIdent.Text+IntToStr(i), RandomPassword(30));
    dtStart := Now;
    ini.UpdateFile;
    dtEnde  := Now;
  finally
    ini.Free;
  end;
    // Hier bitte die Startzeit von der Endezeit abziehen und nicht andersherum.
    // Sonst bekommt man eine negative Zeit, der man einfach das Vorzeichen nimmt und dann suggeriert, man habe eine positive Zeitdifferenz ;-)
    memLog.Lines.Add('MEM (' +   IntToStr(rbgValues.Tag) +'): '+FormatDateTime('ss.zzz',dtEnde - dtStart)+'sec');

Hieraus kann ich nicht entnehmen, dass hier irgendwas ein vielfaches von was anderem dauert:

Code:

-> In der Ausgangslage ist keine Ini-Datei vorhanden
MEM (1000): 00:163sec
MEM (1000): 00:035sec
MEM (1000): 00:024sec
MEM (1000): 00:033sec
-> Hier Ini-Datei gelöscht
MEM (1000): 00:161sec
MEM (1000): 00:023sec
MEM (1000): 00:015sec
MEM (1000): 00:021sec

Beim Ersten gibt es eine Durchschnittszeit von 63,75 ms, beim Zweiten sind es 55 ms.

Auf olympische Wettkämpfe übertragen ergibt das (gerundet) einen Unterschied von 9 hunderstel Sekunden zwischen dem Sieger und dem Zweitplazierten.

Mir scheint, dass dann, wenn eine INI-Datei vorhanden ist, alles "wesentlich" schneller zu sein, als wenn keine INI-Datei vorhanden wäre.

Diese Zeitunteschiede können schon allein dadurch entstehen, dass beim Schreiben der Schreibkopf der Platte zufällig an eine anderen Position war.

Betrachtet man die jeweils ersten Messungen Deiner Messreihen, so beträgt die Zeitdifferenz immerhin immense 2 tausendstel Sekunden.
Ausserdem kann man an den Werten der Messreihen erkennen, dass nach der ersten Messung der Cache sehr stark "zuschlägt". Wann die Daten letztlich physikalisch auf der Platte landen, läßt sich durch Deine Messungen nicht feststellen.

Die Zeitunterschiede, die Du gemessen hast, sind bereits durch die möglichen Differenzen, die sich aus der durchschnittlichen Zugriffszeit der Festplatte ergeben können, vollständig erklärbar.

Schreibst Du da eigentlich ein Programm, das eine Echtzeitverarbeitung durchführt oder eine Anwendung für einen Anwender, der einfach damit arbeiten soll?

Beim Ersteren mögen Deine Bedenken eventuell noch nachvollziehbar sein, beim Zweiten halten ich sie für absolut übertrieben.

Die Zeitunterschiede sind so kurz, dass Du sie als Anwender nicht bemerken kannst. Das menschliche Wahrnehmungsvermögen ist für so kurze Zeitdifferenzen nicht geeignet.

[CodeX]

Huiuiui ... 10 Experten, 11 Meinungen. :)

Zitat:

Zitat von Luckie (Beitrag 1326694)

Wie helfen dir diese Performancemessungen bei der Lösung deines Problems? Murphy [...]

Wenn ich das aktuelle Problem lösen möchte, dann möchte ich das gleich richtig tun. Warum sollte die Performance egal sein? Und warum sollte ich Murphy mehr Freiheiten lassen als nötig?

Zitat:

Zitat von Uwe Raabe (Beitrag 1326704)

Du prüfst die Geschwindigkeit deiner Code-Sequenz, die im Wesentlichen wohl durch die 1000 Aufrufe von RandomPassword und das Anlegen der internen Struktur für TMemInifile beeinflusst wird wird

Diese Code-Sequenz ist in beiden Fällen aber dieselbe. Relevant ist daher nicht die absolute Dauer, sondern die Differenz zwischen mit oder ohne vorhandener Ini-Datei.

Zitat:

Zitat von Uwe Raabe (Beitrag 1326713)

Delphi-Quellcode:

  for I := 0 to cLineCount - 1 do begin
    S := IntToStr(i);
    WriteString('Section' + S, 'Ident' + S, S);
  end;

Du schreibst jedes Mal den exakt selben Inhalt in die Datei. Ich generiere den String absichtlich jedes Mal zufällig, damit zwar die Datei-Struktur gleich bleibt, aber sich der Inhalt ändert. Eben ähnlich wie in der normalen Verwendung. Erklärung nachfolgend...

Zitat:

Zitat von Uwe Raabe (Beitrag 1326713)

Delphi-Quellcode:

  for N := 1 to 100 do begin
    UpdateFile;

Hier schreibst Du 100 Mal dieselbe Datei. Ich bin mir ziemlich sicher, dass Windows hierbei Optimierungs-Routinen beim Schreiben einsetzt, was den Vorgang ad absurdum führt.

Zitat:

Zitat von nahpets (Beitrag 1326719)

Beim Ersten gibt es eine Durchschnittszeit von 63,75 ms, beim Zweiten sind es 55 ms.

:shock: Huch, was soll das? Relevant ist jeweils nur der Schritt vom ersten zum zweiten Durchlauf (163->35 und 161->23), die beiden Folgezeilen sind nur zur Verdeutlichung, dass die Vorwerte kein Zufall waren. Selbstverständlich habe ich hier nicht nur acht mal insgesamt gemessen, sondern viele Dutzend Male in unterschiedlichsten Konstellationen. Ich habe die Erkenntnis dann einfach nur in 10 Zeilen heruntergebrochen, weil keiner hunderte Werte analysieren möchte, wenn sie ohnehin alle das gleiche aussagen.

Zitat:

Zitat von nahpets (Beitrag 1326719)

Ausserdem kann man an den Werten der Messreihen erkennen, dass nach der ersten Messung der Cache sehr stark "zuschlägt".

Letztlich also ein nahes Abbild der realen Bedingungen. :) Der Inhalt der Datei ist wie gesagt vom Aufbau zwar immer gleich (1000 Sections mit je einem Eintrag), der Inhalt aber stets verschieden (jeder Eintrag besteht aus einem zufälligen String).

Zitat:

Zitat von nahpets (Beitrag 1326719)

Ehrlich gesagt finde ich die Diskussion über die Geschwindigkeit langsam absurd

Das sehe ich leider auch so. Allerdings aus anderen Gründen. Dass die Lösung für das ursprüngliche Problem des Datenverlustes sich nicht deutlich in der Performance ausschlagen sollte, ist doch selbstverständlich. Falls nicht, so wundert es mich nicht, warum so viel Software so träge arbeitet. Alle Vorschläge hier zielen auf den gleichen Lösungsansatz ab (Löschen, Verschieben/Umbenennen, Schreiben). Mir kam das suspekt vor, da ich dann ja ständig meine Redundanz vernichte und dann auch noch eine Datenoperation an der Originaldatei durchführe. Deshalb war mein Vorschlag, stattdessen stets beide Dateien zu behalten und per 2xSaveToFile nacheinander hineinzuschreiben. Dass dies mutmaßlich viel langsamer sei, hat mir zum Anlass gegeben, das mal zu überprüfen. Dabei kam bei meinen recht ausführlichen Tests heraus, dass das Erzeugen der Datei wesentlich länger dauert, als hier vermutet wurde.

Und bevor hier jemand zum wiederholten Male fragt, warum Performance und Datensicherheit so wichtig sein sollen, sollte er sich mal Gedanken darüber machen, mit welcher Art von Software er gerne arbeiten möchte.

[nahpets]

Zitat:

Zitat von CodeX

Und bevor hier jemand zum wiederholten Male fragt, warum Performance und Datensicherheit so wichtig sein soll, sollte er sich mal Gedanken darüber machen, mit welcher Art von Software er gerne arbeiten möchte.

Schnelle Software hat schon was, mir ist aber sichere lieber, deshalb wäre ich in dem hier beschriebenen Beispiel durchaus bereit mal die eine oder andere hunderstel Sekunde zu warten.

Der zusätzliche Zeitaufwand wäre eventuell dann von Relevanz, wenn er so zwei-, dreihundert Mal pro Sekunde stattfindet.

Aber konkrete Informationen über die Häufigkeit der durchzuführenden Dateioperationen fehlen leider weiterhin.

Geht's um die "Zeitdifferenzen" beim Programmstart und/oder beim Programmende?
Sorry, meine persönliche Wahrnehmung ist nicht so ausgeprägt, dass ich den Unterschied zwischen der Speicherdauer von 161 ms und 21 ms wahrnehmen könnte.
Insbesondere beim Rechnerstart bzw. beim Runterfahren laufen so viele Prozesse ab, dass ich niemals in der Lage sein würde, hier festzustellen, ob eine (subjektive) Verlangsamung des einen oder anderen Vorganges auf einen bestimmten Prozess oder gar auf ein bestimmtes Schreiben von einer oder zwei Dateien, mit oder Löschung oder Umbenennung einer mehr oder weniger großen Anzahl von Sicherungskopieen zurückzuführen ist.

Ich persönlich wäre da jedenfalls mit 'ner Sekunde zusätzlicher Wartezeit für die Erzeugung von 10 Sicherungskopieen durchaus einverstanden, wenn das Vorhandensein der darin enthaltenen Daten existenziell wichtig ist.

[Uwe Raabe]

Zitat:

Zitat von CodeX (Beitrag 1326722)

Diese Code-Sequenz ist in beiden Fällen aber dieselbe. Relevant ist daher nicht die absolute Dauer, sondern die Differenz zwischen mit oder ohne vorhandener Ini-Datei.

Dann nimm dort doch mal das UpdateFile ganz raus. Damit kannst du dann die Zeit für das Laden bzw. den internen Aufbau des TMemIniFile messen, denn geschrieben wird dann ja nicht. Wie unterscheiden sich nun die Werte mit und ohne UpdateFile?

Wenn du das mal genauer untersuchst, wirst du feststellen, daß die meiste Zeit außerhalb des Aufrufs von UpdateFile verbraucht wird. Es ist ja auch ein Unterschied, ob die INI-Datei bereits beim Create fehlt oder erst beim Aufruf von UpdateFile durch die Umbenennung verschwindet.

Zitat:

Zitat von CodeX (Beitrag 1326722)

Du schreibst jedes Mal den exakt selben Inhalt in die Datei. Ich generiere den String absichtlich jedes Mal zufällig, damit zwar die Datei-Struktur gleich bleibt, aber sich der Inhalt ändert. Eben ähnlich wie in der normalen Verwendung.

Für den Schreibvorgang ist nur der aktuelle Inhalt bzw. die Größe der zu schreibenden Datei relevant. Bei TMemIniFile wird ja nicht in die bestehende Datei geschrieben sondern über CreateFile die Datei neu erzeugt und eine eventuell vorhandene überschrieben. Ich verwende ganz bewusst immer denselben Inhalt um Schwankungen zu vermeiden und die gemessenenen Werte vergleichbar zu machen.

Zitat:

Zitat von CodeX (Beitrag 1326722)

Hier schreibst Du 100 Mal dieselbe Datei. Ich bin mir ziemlich sicher, dass Windows hierbei Optimierungs-Routinen beim Schreiben einsetzt, was den Vorgang ad absurdum führt.

Das kannst du leicht überprüfen, indem du eben nur einmal das UpdateFile aufrufst und den Faktor bei der Zeitermittlung auf 1 setzt. Der ermittelte Wert wird zumindest in der gleichen Größenordnung liegen.

Aber ich habe hier schon mehr geschrieben, als nötig ist. Mag jeder selber mit den Informationen anfangen was er für richtig hält.

[CodeX]

Zitat:

Zitat von himitsu (Beitrag 1326714)

Jemand auch an das FLUSH beim Schreiben gedacht?
Tipp: TStringList -> TFileStream -> FlushFileBuffers

Willst Du damit andeuten, dass nach einem UpdateFile bzw. genauer nach dem darin enthaltenen List.SaveToFile() die Datei noch gar nicht wirklich geschrieben wurde? :o

[nahpets]

Schonmal was von Cache gehört? Den schreibt das Betriebssystem dann weg, wenn es "Zeit und Lust" dazu hat.

Und die Festplatte hat (gewöhnlich) auch noch 'nen Cache und schreibt erst endgültig auf die Platte, wenn sie "Zeit und Lust" hat.

Deshalb geht ja auch so manches Schreiben und Lesen viel schneller, als man es bei den Zugriffzeiten der Festplatten erwarten sollte.

Mehr zum Thema:
https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

https://de.wikipedia.org/wiki/Festplattencache

Das sind alles "Optionen" die Dir jedwede Erhöhung der Performanz und Sicherheit zunichte machen können, wenn da zwischendurch der "Saft" weg ist.