Program hat nach Programmstart bereits ~50MB von der Festplatte gelesen?

[Jim Carrey]

Ich habe heute mal im Taskmanager nachgeschaut, wieviel Bytes mein Programm unmittelbar nach Programmstart von der Festplatte gelesen hat > E/A-Bytes (Lesen).
Ich habe eigentlich maximal ein paar KB erwartet. Aber ich war leicht erschrocken.
Es sind sage und schreibe 50 MB, die bereits nach Programmstart von der Festplatte gelesen wurden.
Zum Vergleich: Notepad++ mit ein paar offenen Tabs ~0,5 MB nach Programmstart.

Nun meine Frage:
wie kommt das zustande?

Bei Programmstart werden zwei Ini-Dateien ausgelesen.
Einmal die Programmeinstellungen (2 KB, 2 Sections) und einmal etwas anderes, was eine StringTree füllt (33 KB, 30+ Sections [jede Section hat 38 Einträge]).

Wie kommen da plötzlich ... 50 Megabyte zustande?

Ich benutze bereits, damit es ein paar Müüüü schneller ist, TMemIniFile statt TIniFile.

[Uwe Raabe]

Liegt vielleicht am Debug-Modus?

[Delphi-Laie]

Und nur TIniFile?

[Jim Carrey]

An so etwas hatte ich auch gedacht, aber nur desinteressiert bis ich festellen musste, dass ich im Release-Modus bin.
Einen Übeltäter habe ich jetzt gefunden.

Ich habe an einer Stelle im Code 30+x eine Textdatei geladen (30+ = die Anzahl meiner Sections).
Diese Funktion wird 30+x aufgerufen. Ich habe nun vorerst eine Überprüfung eingebaut, ob die Datei überhaupt geladen werden muss. Weiteres mache ich später.

Ich bin nun von 50 MB runter auf 7 MB.
Aber das erklärt mir noch immer nicht, warum beim Laden einer <50 KB Textdatei, und sei es 10x Laden der Datei, insgesamt auf 7 MB "gelesen" kommt.

Zitat:

Und nur TIniFile?

Was genau meinst du damit?

[Delphi-Laie]

Na, nur TIniFile statt TMemIniFile verwenden.

Der Prozeßmonitor oder Prozeßexplorer der Sysinternals sollte beim Aufspüren des Problems helfen.

[Jim Carrey]

Ob TIni oder TMemIni hat keinerlei Unterschied gebracht. Ich finde TMemIniFile sogar durchaus besser, da es weniger Arbeit bedeutet.
In der heutigen modernen Zeit eigentlich relativ.... relativ.... aber immerhin.

Wenn ich auch nur eine einzige Zeile mit etwa 50 Zeichen in eine txt-Datei schreibe (StringList => SaveToFile), dann springt der Wert bei "Schreiben" im Taskmanager direkt 500 KB hoch.
Ich mein... einerseits möchte ich die Zugriffe so gering wie möglich halten anderserseits muss ich doch die Programmeinstellungen laden!

[jaenicke]

Zitat:

Zitat von Delphi-Laie (Beitrag 1352770)

Na, nur TIniFile statt TMemIniFile verwenden.

TIniFile benutzt leider die 16-Bit Kompatibilitätsroutinen der Windows API, die nur aus Kompatibilitätsgründen zu Windows 3.x noch vorhanden sind. Auch die Fehler / Features dieser Funktionen sind dementsprechend vorhanden.

Deshalb ist TMemIniFile, das eine echte und schnellere Delphiimplementierung ist, die deutlich bessere Alternative, wenn man noch INIs nutzen möchte.

Zitat:

Zitat von Jim Carrey (Beitrag 1352771)

Wenn ich auch nur eine einzige Zeile mit etwa 50 Zeichen in eine txt-Datei schreibe (StringList => SaveToFile), dann springt der Wert bei "Schreiben" im Taskmanager direkt 500 KB hoch.

SaveToFile macht was der Name sagt. Es speichert die Stringliste komplett in die Datei. Ob du dabei eine oder 100 Zeilen hinzugefügt hast, interessiert dabei nicht.

[Jim Carrey]

Zitat:

wenn man noch INIs nutzen möchte.

Mache ich nur der benutzerfreundlichkeit wegen. Ich hasse Programme, wo man nicht mal selber eben schnell etwas mit Notepad in den Einstellungen ändern kann.
Ich werde dann nun von TIniFile komplett auf TMemIniFile umstellen und kann nur hoffen, dass ich UpdateFile; nicht irgendwann mal vergesse :lol:

Zitat:

SaveToFile macht was der Name sagt. Es speichert die Stringliste komplett in die Datei.

Mh mal gucken. Werde mir dann irgendwas bauen, um das zu umgehen. Jetzt spontan denke ich an die alten Routinen wie AssignFile und dann eventuell noch die AppendAllText aus TFile.

[jaenicke]

Zitat:

Zitat von Jim Carrey (Beitrag 1352774)

Mache ich nur der benutzerfreundlichkeit wegen. Ich hasse Programme, wo man nicht mal selber eben schnell etwas mit Notepad in den Einstellungen ändern kann.

Wir benutzen nur noch XML-Dateien. Da kann man die Daten besser strukturiert ablegen. Insbesondere für die manuelle Bearbeitung ist das durchaus hilfreich.

Zitat:

Zitat von Jim Carrey (Beitrag 1352774)

Mh mal gucken. Werde mir dann irgendwas bauen, um das zu umgehen. Jetzt spontan denke ich an die alten Routinen wie AssignFile und dann eventuell noch die AppendAllText aus TFile.

Da stellt sich schon die Frage, ob sich das lohnt und sinnvoll ist. ;-)
Wenn der Quelltext hinterher z.B. unübersichtlicher ist, schränken solche Optimierungen die Wartbarkeit ein.

[Jim Carrey]

Die Stellen, wo es für mich wichtig wäre AppendAllText statt LoadFromFile+SaveToFile zu benutzen, kann ich an einer Hand abzählen :thumb:

[himitsu]

TIniFile arbeitet mit der entsprechenden WinAPI

Und dort wird für JEDEN EINZELNEN Zugriff auf einen Wert/Gruppe die Datei komplett neu öffnet/geladen/geparst und am Ende wieder komplett geschrieben (bei Schreibzugriffen).

[Jim Carrey]

Ich habe das Ganze jetzt mal ein wenig abgeändert.
Beim Startvorgang meines Programms wird die Ini-Datei einmalig geladen und dann erst wieder freigegeben, wenn das Formular komplett sichtbar ist. Das mache ich über das OnPaint-Event (WMFormVisible, habe ich im Forum schon einmal geposted).

Diese einmalig geladene Ini-Datei wird dann vom Startvorgang (DPR-Datei) bis OnPaint verwendet.
Vorher wurde die mindestens 2 dutzend male geladen.

[Fritzew]

Jetzt bin ich verwirrt,

Zitat:

Diese einmalig geladene Ini-Datei wird dann vom Startvorgang (DPR-Datei) bis OnPaint verwendet.

Du liest Einstellungen für Dein Programm und machst das an einem visuellen Ereignis fest.
Das verstehe ich jetzt nicht. Was haben die Einstellungen mit dem visuellen Teil zu tun?

Meiner Meinung nach:

Beim erzeugen der Klasse (Form) werden die Einstellungen gelesen und gut ist.

Mischen von Funktionalität und visuellen Sachen ist einfach nicht gut.

Spätestens bei dem Versuch so ein Programm auf eine andere Plattform zu bekommen hast Du ein Problem.


Überdenke doch mal das Design

Gruss Fritz

[Jim Carrey]

Zitat:

Mischen von Funktionalität und visuellen Sachen ist einfach nicht gut.

In meinem Fall funktioniert das einwandfrei. Ich werde es irgendwann mal abändern, aber aktuell nicht.

Zitat:

Spätestens bei dem Versuch so ein Programm auf eine andere Plattform zu bekommen hast Du ein Problem.

Andere Plattformen als Windows interessieren mich genau soviel wie die C++ - kein bisschen :P

[Delphi-Laie]

Zitat:

Zitat von jaenicke (Beitrag 1352773)

Deshalb ist TMemIniFile, das eine echte und schnellere Delphiimplementierung ist, die deutlich bessere Alternative, wenn man noch INIs nutzen möchte.

Das glaube ich Dir auf's Wort. Also gleich darangemacht, aber leider kann man TIniFile nicht einfach mit TMemIniFile ersetzen und den auf die IniFiles bezogenen Quelltext ansonsten belassen. Eine geschlagene Stunde experimentierte ich - auch mit dem just empfohlenen Process Monitor. Des Rätsels Lösung: Um das Schreiben auf den Datenträger zu erzwingen, ist - zusätzlich zu TIniFile - ein UpdateFile nötig.

[Jim Carrey]

Zitat:

Das glaube ich Dir auf's Wort. Also gleich darangemacht, aber leider kann man TIniFile nicht einfach mit TMemIniFile ersetzen und den auf die IniFiles bezogenen Quelltext ansonsten belassen.

Wieso das nicht? bei mir ging es.

Man muss nur vor dem Free UpdateFile machen, was ein wenig umständiglich ist.

[Uwe Raabe]

Zitat:

Zitat von Delphi-Laie (Beitrag 1352807)

Das glaube ich Dir auf's Wort. Also gleich darangemacht, aber leider kann man TIniFile nicht einfach mit TMemIniFile ersetzen und den auf die IniFiles bezogenen Quelltext ansonsten belassen. Eine geschlagene Stunde experimentierte ich - auch mit dem just empfohlenen Process Monitor. Des Rätsels Lösung: Um das Schreiben auf den Datenträger zu erzwingen, ist - zusätzlich zu TIniFile - ein UpdateFile nötig.

Nicht zwingend! Zutaten: Eine aktuelle Delphi-Version und

Delphi-Quellcode:

AutoSave

. Siehe hier.

Natürlich kann man nicht an allen Stellen

Delphi-Quellcode:

TIniFile

verwenden und dann hintenrum ein

Delphi-Quellcode:

TMemInifile

unterschieben. Dafür gibt es eben

Delphi-Quellcode:

TCustomIniFile

.

[Sherlock]

Blöde Frage: Wie groß ist Deine Exe? Die gilt es ja auch beim Start einzulesen.

Sherlock

[bra]

Eventuell sind das auch irgendwelche DLLs, die nachgeladen werden?

[Jim Carrey]

Keine DLLs. Die exe ist 6MB groß.

Einen Fehler habe ich mittlerweile eliminimiert. AUßerdem habe ich überall auf TCustomIniFile und TMemIniFile umgstellt. Mal gucken wie sich das nun ändert, habe es noch nich getestet.

[bra]

Zitat:

Zitat von Jim Carrey (Beitrag 1352844)

Keine DLLs. Die exe ist 6MB groß.

Dir ist bewusst, dass fast jedes Programm irgendwelche DLLs nachlädt?

[Jim Carrey]

Zitat:

Dir ist bewusst, dass fast jedes Programm irgendwelche DLLs nachlädt?

Dann ist deine Fragestellug falsch:

Zitat:

Eventuell sind das auch irgendwelche DLLs, die nachgeladen werden?

Denn erst fragst du, ob DLLs nachgeladen werden und nun sagst du, dass definitiv welche nachgeladen werden :lol:

Was ich meinte sind -eigene- DLLs.

Das kann aber nix mit den DLLs usw zu tun haben. Öffne mal ein neues Projekt und siehe im Taskmanager "Lesen/Schreiben". Lesen steht bei mir bei einem frischen Projekt 60 Byte.

[himitsu]

DLLs werden per MMF eingebunden.
In wie weit deren "Lesen" (beim Zugriff/Ausführen) in den IO-Counter einfließen weiß ich nicht, da dort das Lesen/Schreiben "intern" über die Speicherverwaltung des Windows laufen.