Einzelnen Beitrag anzeigen

CodeX

Registriert seit: 30. Okt 2004
471 Beiträge
 
Delphi 12 Athens
 
#51

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

  Alt 12. Jan 2016, 12:18
Huiuiui ... 10 Experten, 11 Meinungen.

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?

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.

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

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.

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.

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

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.
Nur Delphi schafft es, einem ein Lächeln zu schenken, wenn man sich beim Schreiben von := vertippt und stattdessen ein :) erscheint.

Geändert von CodeX (12. Jan 2016 um 12:27 Uhr)
  Mit Zitat antworten Zitat