Grenzen von INI

[redox]

Zitat von Popov:

Ich hab zuerst den 32 Zeilen Code geschrieben. Da habe ich nach einer Logik geprüft welche Daten es geben kann und welche nicht. Wenn x gleich y ist, kann es die Daten geben, ist es dagegen z, kann es die Daten nicht geben. So in etwa. Also kann man sich auch den Zugriff sparen, der einem sowieso nur sagt, dass es die Daten nicht gibt. Das spart Zeit.

Damit habe ich tatsächlich den Zugriff von 1,844 auf 0,422 reduziert.

Dann hatte ich die Idee, weil irgendwer es mal eingeworfen hat, TMemIniFile statt TIniFile zu nehmen. Der Hinweis war in einem anderen Zusammenhang, aber da ich an der Stelle nur lesen mußte, reichten zwei Änderungen.

Das brachte den Rest, bzw. die 32 Zeilen Änderung wurden fast unwichtig.

Sag's doch gleich, die zwei Zeilen waren TMemIniFile und dessen Flush für's Wegschreiben der Daten...

Ich missbrauche INI-Dateien schon seit Jahren für kleine "Datenbanken", weil's einfach zu einfach (falls man keine zwei oder mehr Instanzen des Programms zulässt) und bequem ist.

Wozu denn der XML- oder JSON-Kram?

Will mir hier jemand die Story vom "toten Pferd" erzählen?

Mit ein paar Zeilen exportiere ich aus der "INI-Datenbank" eine CSV-Datei, mit der fast alle Tabellenkalkulationen (unter Windows und Linux) klarkommen...

Gruß
Redox

[Popov]

Zitat von redox:

Sag's doch gleich, die zwei Zeilen waren TMemIniFile und dessen Flush für's Wegschreiben der Daten...

Wie ich schon sagte, ich hatte das Ganze bereits von 1,8 auf 0,4 Sekunden runter. Klar, ob ich mit einer komplexen Logik zuerst prüfe ob es Dateien geben kann oder TMemIniFile die Ini im Speicher hält und mir keinen Wert liefert, kommt in diesem Fall auf das Gleiche hinaus.