Grenzen von INI

[Popov]

Alles was ich gefunden habe ist schon etwas älter, deshalb wollte ich es noch mal kurz ansprechen. Evtl. gibt es inzwischen neue Erkenntnisse.

Ich überlege in einem Programm mehrere INIs zu einer zusammen zu fügen. Grund ist, dass es auf langsamen System u. U. bis zu einer halben Sekunde dauert bis alles eingelesen ist und das Programm somit starten kann. Das ist nicht lange, aber entweder ich lasse es so und man wundert sich über die lange Ladezeit, baue ein Splashscreen ein damit man sieht, dass da etwas geladen wird, oder ich packe mehrere INIs zu einer INI. Dann wird nur eine Datei geöffnten. Das geht schneller.

Die Frage ist wie es nun mit der Größe der INI aussieht. Liegt die Begrenzung immer noch bei 64 KB oder ist das das Schnee von gestern?

Wenn ja, auf Welchen Systemen gibt es welche Begrenzungen? Ich meine Win 9x, NT, XP, usw. (falls es einer weiß).

Ich hab gerade eine 2 MB große INI erstellt. System XP und Delphi 7. Also bei XP scheint es kein 64 KB grenze zu geben. Die frage ist, seit wenn gibt es die nicht.

Das andere ist die länge des Strings der gespeichert werden kann. Ich hab 2047 Byte gezählt. Ist das korrekt, gibt es eine Möglichkeit über die Grenze zu speichern?

[Bjoerk]

Die 64 K Grenze gibt es spätestens seit D7/XP nicht mehr. Bei TIniFile weiß ich's nicht genau aber bei TMemIniFile können die Strings beliebig lang sein. Schneller sind INI's mit kleinen Abschnitten. (Also besser viele Sections mit wenig Einträgen als wenig Sections mit vielen Einträgen).

[Lemmy]

Hi,

Json ist das neue Ini!

Vorteile Json gegenüber Ini:
* Mehrzeilige Strings kein Problem
* verschachtelte Hierarchien kein Problem
* Arrays,... kein Problem
* Du hast deine Einstellungen gleich in einer Klasse gekapselt.

Du brauchst lediglich einen Parser dazu, bei neueren Delphis (ich glaube ab XE6) ist ja einer von Haus aus verfügbar.

Grüße

[Dejan Vu]

Zitat:

Zitat von Popov (Beitrag 1299007)

...dass es auf langsamen System u. U. bis zu einer halben Sekunde dauert bis alles eingelesen ist und das Programm somit starten kann...man wundert sich über die lange Ladezeit, baue ein Splashscreen ein damit man sieht...

Ist das dein Ernst? Für 0.5 Sekunden willst du einen Splash einblenden? :gruebel:
Weiterhin frage ich mich, was Du alles in den INI-Dateien drin hast.

Wenn es sich um viele gleichförmige Daten handelt, die auch in einer Tabelle platz fänden, käme ein ClientDataSet oder eine kleine Desktop-DB in Frage. Zu ewig langen Konfigurationsdateien (ob nun XML, JSON oder was-weiss-ich) würde ich abraten, dann ist eine DB vermutlich die bessere Wahl.

Was für Daten legst Du denn in so einer INI ab?

[Sir Rufo]

Wo ist denn das Problem mit dem Splash-Screen?

Form anzeigen, in einem Thread die Ini-(oder in welchem auch immer gearteten Format-)Daten laden und beim Beenden des Threads die Form wieder entsorgen. Fettich.

Das ist kein Aufwand sondern eine Fingerübung zum warm werden.

[jobo]

Problem mit Splashscreens gibt es dann, wenn es Probleme gibt.
Ich weiß nicht, was Dejan Vu meint, aber ich find sie nur erträglich, wenn alles glatt geht. Ist vielleicht auch ne Frage, wie gut die gemacht sind.
Erfahrungswerte zeigen, dass sie im Problemfall eher stören und es gibt mindestens ein Programm, für dass ich schon nach command line Schaltern gesucht hab, um sie auszublenden.
Eigenartige StayOnTop Einstellungen, die dafür sorgen, dass die Fehlermeldungen aus dem Ladeprozess überdeckt werden, sodass sich die Form selbst blockiert.

[Sir Rufo]

Hmmm, Exceptions die in einem Thread auftauchen muss ich aktiv zur Anzeige bringen.

Und ja, erst wenn ich es richtig mache, dann funktioniert es richtig ... ist das nicht immer so?

[Bernhard Geyer]

Zitat:

Zitat von Lemmy (Beitrag 1299014)

Json ist das neue Ini!

Wohl eher XML. JSON ist eher das neue SOAP.

[Lemmy]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1299035)

Zitat:

Zitat von Lemmy (Beitrag 1299014)

Json ist das neue Ini!

Wohl eher XML. JSON ist eher das neue SOAP.

http://thedailydeveloper.com/skillsprint14-json/

[Jumpy]

Es gab da meine ich auch mal einen SkillSprint oder sowas dazu, ich meine das war der hier.

Edit: Wo war die rote Box? Naja zumindest ist es nicht der selbe Link :)

[himitsu]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1299035)

Zitat:

Zitat von Lemmy (Beitrag 1299014)

Json ist das neue Ini!

Wohl eher XML. JSON ist eher das neue SOAP.

Alles, was mit INI geht, geht auch mit JSON (und noch mehr)
und alles was mit JSON geht, geht auch mit XML (und mehr).

Jenachdem, was man mindestens benötigt, nimmt man Einwas davon, was Dieses unterstützt.


PS: Registry ist das neue INI.

[Popov]

Zitat:

Zitat von Lemmy (Beitrag 1299014)

Json ist das neue Ini!

Nichts gegen Json, ich bin schon sehr früh drauf aufmerksam geworden und wenn es einfach wäre, ich würde es heute nutzen. Aber ich hab mir dreimal das Delphi dabei zerschossen irgendein Json bei mir zu installieren, nun habe ich es aufgegeben. Laut dem was man so liest ist Json etwas ultraeinfaches. Es kann mehr als Ini und ist nicht so überladen wie Xml. Und wenn man sich anguckt was es so können muss, dann dürfte es nicht kompliziert programmiert sein. Ich frage mich deshalb wieso es nicht einfach eine 1 Unit Erweiterung ist. Einfach einbinden und gut ist es. Alles was ich bisher gefunden habe verlangte entweder eine höhere Delphiversion oder ein Rattenschwanz an anderen Erweiterungen die man vorher installiert haben muss. Somit bleibe ich bei Ini, oder wenn es komplexer werden muss, dann... mal sehen.

Zitat:

Zitat von Dejan Vu (Beitrag 1299027)

Ist das dein Ernst? Für 0.5 Sekunden willst du einen Splash einblenden? :gruebel:

Ja, die Welt ist schon komisch. Vor 100 Jahren hat man sich für die Dinge noch Zeit genommen. Wenn ich aber heute ein Programm starte, dann erwarte ich, dass es sofort da ist. Wenn es nicht sofort da ist, starte ich es sofort noch mal. Eine halbe Sekunde klingt nicht nach viel, es ist aber die Zeit wo man sich fragt wo das Programm bleibt.

[Sherlock]

Nenne mir bitte zwei ernsthafte Programme, die in weniger als 0,5 Sekunden geladen sind. Das ist ja schon die Zeit, die es braucht, bis die Exe aus dem Fileserver geladen wurde. Ich dachte ernsthaft, das wäre ein Fehler von Dir gewesen und du meintest Minute statt Sekunde...

Sherlock

[Jasocul]

Zitat:

Zitat von Popov (Beitrag 1299123)

Wenn es nicht sofort da ist, starte ich es sofort noch mal. Eine halbe Sekunde klingt nicht nach viel, es ist aber die Zeit wo man sich fragt wo das Programm bleibt.

Ein Wimpernschlag dauert ca. 0,1 Sekunde.
Ein Herzschlag ca. 1 Sekunde.
Die Zahl "21" dient als Hilfe, eine Sekunde zu "messen".

Ob bei diesen Zeiten eine halbe Sekunde wirklich ausreicht, um sich zu fragen, ob das Programm schon gestartet ist, bezweifle ich ganz stark. Ab 2 Sekunden würde ich dir vielleicht Recht geben. Es gibt übrigens auch einfache Mittel, einen Mehrfach-Start eines Programmes zu verhindern (Stichwort Mutex).

Ich würde eher das Start-Verhalten grundsätzlich ändern. Die Ini-Datei kann vermutlich auch nach dem Start geladen werden. Möglicherweise auch in einem Thread. Eine Sanduhr während des Ladevorgangs der Ini-Datei kann auch ausreichen.
Ein Splash-Screen der kaum eine halbe Sekunde sichtbar wäre, halte ich für nicht sonderlich sinnvoll. Da blitzt dann höchstens etwas kurz etwas auf.

[Popov]

@Jasocul

Dann lass es nicht 05 s, sonder 1 s sein. Es ist eine merkbare Verzögerung. Und Mutex kenne ich auch, es geht aber nicht dadrum.

Zitat:

Ich würde eher das Start-Verhalten grundsätzlich ändern. Die Ini-Datei kann vermutlich auch nach dem Start geladen werden.

Wie ich schon im Einganspost geschrieben habe, eine Verzögerung merkt man nur auf alten Systemen mit langsamen Festplatten. Das Problem existiert also nicht wirklich. Der Aufwand sollte also dem Nutzen entsprechen. Und hier geht es um die ganz wenigen Rechner auf denen es eine Verzögerung von einer halben Sekunde gibt.

Letztendlich sind die INIs das Problem. Ich muss mehre INIs öffnen, das kostet Zeit. Alles in einer INI und man würde es nicht merken.

[p80286]

Zurück zur Ausgangsfrage:
Irgendwo existiert da diese ominöse Grenze,(hier gab's mal was dazu) weil ein veraltetes API für die Zugriffe auf das .INI-File genutzt wird. Darum ist Deine Idee mit dem großen INI-File auch nicht soo gut weil dann die Zugriffe noch länger dauern.
(Immer vorrausgesetzt ich erinnere mich richtig!)

Gruß
K-H
doch noch gefunden:http://www.delphipraxis.net/170130-i...on-1010-a.html

[Dalai]

Ich glaube mich zu erinnern, dass es zu Total Commander Diskussionen gab, warum denn bestimmte Einträge nicht gelesen wurden (war schon irgendein NT-basierendes OS, vermutlich Win2k oder XP). Als mögliche Ursache wurde dann eine Grenze von 64 KiB pro Abschnitt/Section angegeben und nach Verkleinerung einer Section unter diesen Wert lief alles wieder.

Ich weiß nicht, ob das auf aktuellen Windows-Versionen noch relevant ist, aber man kann das ja mal ausprobieren, aber zumindest im Hinterkopf behalten.

MfG Dalai

[BUG]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1299035)

Wohl eher XML. JSON ist eher das neue SOAP.

REST ist das neue SOAP (naja, nicht ganz so schlimm). JSON ist das für REST was XML für SOAP ist (obwohl REST nicht auf JSON als Datenaustauschformat beschränkt ist) :stupid:

Ich finde TOML für Konfigurationsdateien interessant, aber leider ist das noch nicht stabil spezifiziert und noch nicht verbreitet genug.

[himitsu]

INI, über die INI-WinAPI, wurde in einen 64-KB-Puffer (eine komplette Speicherseite im virtuellen Arbeitsspeicher) eingelesen und da drin verarbeitet (und das bei jedem einzelnen Lese/Schreibzugrif jedes einzelnen Wertes komplett von Vorne)
Lösung: TMemIniFile (das benutzt nicht diese API und ist auch noch schneller)

INI hat aber einen Vorteil, da dort jede Zeile einzeln analysiert wird, ist es der API egal, ob die Datei kaputt ist (also in der Datenstruktur), denn solange die SectionZeile und die eine WertZeile bis zum

Delphi-Quellcode:

=

OK sind, kann dieser Wert auch ausgelesen werden.

[Der schöne Günther]

Eigentlich bin ich jemand der immer gleich auf den Hype-Train aufspringt. Wenn etwas neu ist, ist es gleich cool und automatisch besser als das alte Gegenstück.

Nichts gegen JSON, sein Siegeszug ist verdient. Aber ich kann mich weiterhin nicht damit anfreunden, einfache Anwendungseinstellungen jetzt statt in einer flachen .ini-Datei in einer hierarchischen JSON-Datei abzulegen. Ich habe oft die Situation dass beim Kunden vor Ort noch etwas angepasst werden muss. Und jeder nicht allzu PC-versierte Techniker kann eine ini-Datei bearbeiten. XML oder JSON bringt solche Leute zur Verzweiflung. Deshalb sehe ich weiterhin immer davon ab.

[Dejan Vu]

Zitat:

Zitat von jobo (Beitrag 1299031)

Ich weiß nicht, was Dejan Vu meint,

Das 0.5 Sekunden vielleicht etwas kurz ist, um sich Gedanken über einen Splash-Screen zu machen, eigentlich stand das da. So schwer ist das doch nun wirklich nicht zu verstehen.

Ich würde immer noch gerne wissen, was das denn für Einstellungen sind, die über mehrere INI-Dateien verteilt sind und mehr als 0,5 Sekunden benötigen (auf langsamen Systemen), bis sie geladen sind. Ich kann mir vorstellen, zur Not eine EAV-Tabelle zu verwenden.

Die Registry würde ich im Übrigen nicht mit so vielen Einstellungen zumüllen, aber das ist vielleicht auch Anssichtsache.
Hier ist eine interessante Diskussion zu dem Thema.

[BUG]

OK, einmal noch, dann bin ich ruhig :tongue: :mrgreen:

Zitat:

Zitat von Der schöne Günther (Beitrag 1299182)

Und jeder nicht allzu PC-versierte Techniker kann eine ini-Datei bearbeiten. XML oder JSON bringt solche Leute zur Verzweiflung. Deshalb sehe ich weiterhin immer davon ab.

Das ist der Aspekt der mir an TOML gefällt: Wenn man keine Verschachtelung braucht, sieht das Ding quasi wie eine INI-Datei aus. Wenn man Verschachtelung braucht, ist sie da (und sieht trotzdem einfach aus).

Umfangreiche XML-Dokumente per Hand (Texteditor) editieren ist einfach ätzend. JSON ist da angenehmer, dabei fallen aber viele Vorteile von XML weg (Tool-Unterstützung) ... und angenehm geht auch anders.

[Popov]

Zitat:

Zitat von Dejan Vu (Beitrag 1299185)

Ich würde immer noch gerne wissen, was das denn für Einstellungen sind, die über mehrere INI-Dateien verteilt sind und mehr als 0,5 Sekunden benötigen (auf langsamen Systemen)

Ich hab nie geschrieben, dass es Einstellungen sind. Es sind Daten, einfach nur Daten. Ich hätte sie auch in einer anderen Form speichern können, ich konnte sie auch als Ini speichern.

@Der schöne Günther

Der Grund wieso ich immer noch gerne Ini nutze, mal davon abgesehen, dass es sich bei dem oberen Beispiel nur um Daten handelt, die man auch anders hätte speichern können, ist, dass man mit zwei oder drei Handgriffen alles sofort in die Registry verfrachten kann. Delphi acht den Wechsel zwischen Ini und Registry sehr einfach.

[Dejan Vu]

Zitat:

Zitat von Popov (Beitrag 1299207)

Zitat:

Zitat von Dejan Vu (Beitrag 1299185)

Ich würde immer noch gerne wissen, was das denn für Einstellungen sind, die über mehrere INI-Dateien verteilt sind und mehr als 0,5 Sekunden benötigen (auf langsamen Systemen)

Ich hab nie geschrieben, dass es Einstellungen sind. Es sind Daten, einfach nur Daten. Ich hätte sie auch in einer anderen Form speichern können, ich konnte sie auch als Ini speichern.

Na ja, Du hast die Frage, was für Daten es sind, nicht beantwortet, da lag es nahe, das es auch 'Einstellungen' sein könnten, also eher heterogene Daten. Homogene Daten => Tabelle => DataSet-Derivat. Heterogene Daten => EAV => JSON, XML, INI oder Tabelle => DataSet.

Aber: Blöd, das Du keine meiner Vorschläge auch nur im Ansatz in Erwägung und andere Dinge eh nicht in Betracht ziehst, vor allen Dingen diesem neumodischen Krimskrams wie JSON oder TOML. Dann bleib bei INI und verwende es als Datenspeicher. Dann musst du eben mit der immensen Ladezeit leben. Bau einen Splash dazu und biete noch ein Schnellschachspiel an, damit man die Wartezeit sinnvoll überbrücken kann :lol:

[Popov]

Dejan Vu, Regel #1 ist: mach es einfach. Warum also Daten die man mit Gruppe/Name/Wert zuordnen kann, komplex speichern? Man kann was anderes nehmen, man kann dafür auch IniFile nehmen. Und zweitens, das Ini Format kann jeder selbst nach 40 Jahren verarbeiten. Zur Not geht das mit einem Notepad.

Und drittens, die Daten werden schon seit geraumer Zeit gespeichert. Eine Entscheidung ob man vielleicht was anderes nimmt, ergibt sich nicht. Das kann man in Zukunft machen, hier nicht mehr.

Und viertens, eine Umstellung auf eine Datei ist mit drei Zeilen Code erledigt.

Und fünftens, ich bin stets offen für neumodischen Krimskrams. Nenne mir eine JSON Unit die in Delphi 7 funktioniert, und ich arbeite in Zukunft damit.

Und sechstens, trink einen Kamilletee. Sowas ist nicht wert sich aufzuregen. Die Welt ist kompliziert genug.

[jobo]

Zitat:

Zitat von Sir Rufo (Beitrag 1299032)

Hmmm, Exceptions die in einem Thread auftauchen muss ich aktiv zur Anzeige bringen.
Und ja, erst wenn ich es richtig mache, dann funktioniert es richtig ... ist das nicht immer so?

Klar, ich verweise an der Stelle auf Deine Signatur!
Offenbar ist es nicht so einfach oder keine Selbstverständlichkeit, das richtig zu machen. Hängt natürlich auch stark davon ab, was technisch in der Zeit alles passiert. Von einem der genannten Programme weiß ich, dass es Delphi ist, aber Einblicke habe ich da natürlich nicht.
Mein Beitrag sollte eher als Hinweis dienen, den "Aufwand" für Splash dann bitte auch richtig einzuschätzen und es ordentlich zu machen.
Das Entsetzen, für max 0,5 Sekunden Wartezeit ein Splash zu spendieren teile ich nicht. Je anspruchsvoller desto besser. Software darf auch Spaß machen, wenn es kein Game ist.
Ich hab eher den Verdacht, dass einige hier ein schlechtes Gewissen bekommen, wenn jemand für ein paar Wimpernschläge so einen Aufwand treibt.

[Luckie]

Also ich halte es immer so: Wenn ich nach der Grenze von irgendwas fragen muss, dann mache ich was falsch. Weil in der Regel ist Windows so ausgelegt, dass man äußerst selten an irgendeine Grenze stößt.

Alternativ nimm einfach eine Textdatei und entwickle eine eigen Datenstruktur. da du bisher mit Ini-Dateien gearbeitet hast, kann die Datenstruktur nicht so komplex sein.

[DeddyH]

Zitat:

Zitat von Popov (Beitrag 1299229)

Nenne mir eine JSON Unit die in Delphi 7 funktioniert, und ich arbeite in Zukunft damit.

SuperObject

[jobo]

Zitat:

Zitat von Luckie (Beitrag 1299234)

Also ich halte es immer so: Wenn ich nach der Grenze von irgendwas fragen muss, dann mache ich was falsch. Weil in der Regel ist Windows so ausgelegt, dass man äußerst selten an irgendeine Grenze stößt.

Mmh, diese Herangehensweise finde ich jetzt aber sehr eigenartig. Ist nicht mindestens im Zweifel eine genaue Grenzwertbetrachtung notwendig?
Finde ich ehrlich gesagt überraschend, das hier so zu lesen, wo gern schon mal auf Ebene von Variablen um Bits, Bytes, Integers gestritten wird.

[Bernhard Geyer]

Zitat:

Zitat von Luckie (Beitrag 1299234)

Alternativ nimm einfach eine Textdatei und entwickle eine eigen Datenstruktur.

XML? :-)

Zum Ursprungsproblem: Bist du dir sicher das die Inidateien als Datei das Problem darstellt? Hast du ein Profiling mit AQTime und Co. durchgeführt.
Oft kommt man dann dahinter das nicht die Datei das Problem darstellt sondern die Programmierung drum herum? So hat es bei uns merklich was gebracht an relevanten stellen const bei den Parametern zu definieren so das (an Zentralen Funktionen die Mio.-Fach aufgerufen werden) das Kopieren von Strings (Arbeiten unter D6 mit WideString, beim normalen String dürfte das zwar auch merklich sein, aber nicht so stark) ein bremsende Aktion war.

[Popov]

Zitat:

Zitat von Luckie (Beitrag 1299234)

Wenn ich nach der Grenze von irgendwas fragen muss, dann mache ich was falsch. Weil in der Regel ist Windows so ausgelegt, dass man äußerst selten an irgendeine Grenze stößt.

Die Grenzen von INI sind mir mehr oder weniger bekannt. Auch bin ich in der Lage ein Testprogramm zu schreiben das mir die Grenzen zur Not aufzeigt. Bevor ich also gefragt habe, wußte ich bereits, dass ein Wert, nicht die Zeilenlänge, 2047 lang sein kann und auch die ganze INI paar MB groß sein darf.

Was ich aber nicht weiß ist, seit wann das so ist, d. h. ob ich eine Einschränkung für Windowsversion mit einbauen soll, bzw. ob sich das lohnt, usw.


@DeddyH

Danke, werde es testen. Der erste Test sieht aber nicht gut aus, da gibt es Fehlermeldungen. Ich werde aber prüfen ob ich es umprogrammieren kann

[Bernhard Geyer]

Zitat:

Zitat von Popov (Beitrag 1299239)

Was ich aber nicht weiß ist, seit wann das so ist, d. h. ob ich eine Einschränkung für Windowsversion mit einbauen soll, bzw. ob sich das lohnt, usw.

Für in 2015 relevante Windows-Versionen (XP und neuer) gibt die Einschränkungen nicht mehr.
Es könnte sein das Win9x die noch hat, aber in 2015 ist Win9x eh irrelevant (oder soll dein Programm noch für die potentiellen 3 User sein die noch 95 installiert haben?).

[Popov]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1299240)

Es könnte sein das Win9x die noch hat, aber in 2015 ist Win9x eh irrelevant...

Stimmt, man sollte dann aber entweder ein Hinweis geben, das Programm funktioniert nicht mit dieser Windows-Version, ober sich fragen, langsame Systeme hin oder her, 0,5 Sekunden auch hin oder her, ich lasse alles bei altem und dann ist das Programm auch zu 95 kompatibel.

Letztendlich geht es weniger um das aktuelle Programm, es geht vielmehr um die Grenzen zu kennen, bzw. wann es welche gab. Aktuell gibt es keine oder sie können umgangen werden.

[Bernhard Geyer]

Zitat:

Zitat von Popov (Beitrag 1299242)

Stimmt, man sollte dann aber entweder ein Hinweis geben, das Programm funktioniert nicht mit dieser Windows-Version,

Machen doch die meisten Programme. Wir bringen unter NT z.B. eine Meldung das das OS zu alt ist. Unter W9x dürfte es vermutlich gar nicht mal startbar sein

Zitat:

Zitat von Popov (Beitrag 1299242)

... dann ist das Programm auch zu 95 kompatibel.

Du testest es dann sicherlich auch? oder vermutest du das nur? Z.B. gabs selbst mit D6 schon einen patch-stand der nicht mehr unter W9x lief. Erst mit einem Hotfix lief wieder. Und wenn du Third-Party-Kompos einsetzt ist es fraglich ob die noch gegen Win9x Prüfen.

Zitat:

Zitat von Popov (Beitrag 1299242)

... es geht vielmehr um die Grenzen zu kennen, bzw. wann es welche gab.

Microsoft dokumentiert sowas eigentlich ganz gut. Aber bei solch alten OS-Versionen und mehr oder minder abgekündigten APIS wird man evtl. lange den passenden Artikel suchen müssen.

[Luckie]

Zitat:

Zitat von jobo (Beitrag 1299237)

Mmh, diese Herangehensweise finde ich jetzt aber sehr eigenartig. Ist nicht mindestens im Zweifel eine genaue Grenzwertbetrachtung notwendig?
Finde ich ehrlich gesagt überraschend, das hier so zu lesen, wo gern schon mal auf Ebene von Variablen um Bits, Bytes, Integers gestritten wird.

Du hast mich nicht verstanden. das datentypen in ihrer Größe beschränkt sind, ist klar. Es geht um Fragen wie zum Beispiel: "Kann ich aus meinen Prozess 1.000 Threads gleichzeitig starten, weil ich sie brauche." Dann macht man mit ziemlicher Sicherheit was falsch.

[Bjoerk]

Zitat:

Zitat von Popov (Beitrag 1299239)

Die Grenzen von INI sind mir mehr oder weniger bekannt. [..]

Die Grenze einer Inifile ist seit XP nicht die Größe sondern der Zeitaufwand beim Suchen des Eintrages. Was eine Inifile langsam macht ist, daß der Eintrag gesucht werden muß. Deshalb sind viele kleine Sections auch schneller als wenige große. Außerdem werden [ Section ] zu [Section] und Ident = Value zu Ident=Value korrigiert (Stringverarbeitung). Und, Default wird nicht zwischen Groß und Kleinschreibung unterscheiden, also brauchts ein AnsiLowerCase, und das ist sehr langsam. TMemInFile hat eine property CaseSensitive, das bringt ganz schön was.

[Chemiker]

Hallo Popov,

INI-Dateien steht für Initialisierungsdatei diese sind eigentlich für Einstellungen des Programms mal von MS eingeführt worden. Wenn Du sowieso mehrere INI-Dateien hast vielleicht ist es möglich diese erst aufzurufen, wenn sie konkret gebraucht werden.
Wenn es normale Daten sind und Du keine DB verwenden willst würde ich einen TFileStream benutzen.

Bis bald
Chemiker

[Popov]

Hallo Chemiker,

ich weiß was Ini bedeutet und ich weiß auch, dass es eigentlich für Einstellungen gedacht ist. Man kann damit aber auch sonstige Informationen speichern. Und bevor mir noch einer sagt, dass für sowas eigentlich Datenbanken gedacht sind, nun, bevor ich eine Server aufsetze oder sonstige DLLs einbauen muss usw., nur um etwas Simples zu speichern...

Aber bevor mir einer hier Resistenz gegen gute Tipps vorwirft, auch wenn ich über einiges diskutiere, so setzte ich viele Tipps dann doch um. Das mit den 0.5 Sekunden war übrigens nur geschätzt, ich hab es dann nachgemessen, es waren 1,844 Sekunden. Dann habe optimiert (nur zwei Zeilen) und es wurden 0,186 Sekunden. Dann noch mehr optimiert (dieses Mal 32 Zeilen) und es wurden 0,177 Sekunden. Und das auf einem alten langsamen System. Damit kann ich leben.

Also vielen Dank für die guten Tipps, die waren nicht umsonst. Gelegentlich inspirieren sie einen zu paar Änderungen.

[Bernhard Geyer]

Zitat:

Zitat von Popov (Beitrag 1299307)

Dann habe optimiert (nur zwei Zeilen) und es wurden 0,186 Sekunden. Dann noch mehr optimiert (dieses Mal 32 Zeilen) und es wurden 0,177 Sekunden. Und das auf einem alten langsamen System. Damit kann ich leben.

Also vielen Dank für die guten Tipps, die waren nicht umsonst. Gelegentlich inspirieren sie einen zu paar Änderungen.

Verrätst du uns was dies zwei Zeilen waren (Sowas wie hier http://www.delphipraxis.net/1299238-post30.html)

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