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

[CodeX]

Huiuiui ... 10 Experten, 11 Meinungen.

Zitat von Luckie:

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 von Uwe Raabe:

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 von Uwe Raabe:

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 von Uwe Raabe:

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 von nahpets:

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

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 von nahpets:

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 von nahpets:

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 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 von CodeX:

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 von CodeX:

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 von CodeX:

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 von himitsu:

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?

[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.