Autor |
Beitrag |
Heiko
Beiträge: 3169
Erhaltene Danke: 11
|
Verfasst: Mi 13.02.08 17:39
Die Streams brucht du doch nur zum Laden bzw. Speichern. Das zeug dazwischen würde ich nicht per Streams machen, da dass eine aufwändige umkopiererrei ist.
PS: Kannst du mal von deinem letzten Post kurz Pseudocode oder ähnliches geben, damit ich weiß, was du meinst? Denn ich sehe da gerade nicht ganz durch, was du genau meinst (oder ich muss ihn mir später nochmal angucken, wenn meine Gedanken von der Schule endgültig erlöst sind )
|
|
Silas
Beiträge: 478
Windows XP Home
Delphi 2005, RAD Studio 2007, MASM32, FASM, SharpDevelop 3.0
|
Verfasst: Mi 13.02.08 18:02
_________________ Religionskriege sind nur Streitigkeiten darüber, wer den cooleren imaginären Freund hat
|
|
Heiko
Beiträge: 3169
Erhaltene Danke: 11
|
Verfasst: Mi 13.02.08 21:08
Silas hat folgendes geschrieben: | Ich mein, einen Parser von TStream abzuleiten macht wenig Sinn, weil ein Parser ja kein Stream ist |
Ah k, dass meinst du. Mich hatte letztens dieser Satz gestört :
Silas hat folgendes geschrieben: | dass der Parser selbst also nur noch mit Streams arbeitet |
Du meinst also, dass der Dateiconstruktor den Streamconstructor aufruft, nur mit nem selbst erzeugtem Stream. Sag das doch gleich .
|
|
Silas
Beiträge: 478
Windows XP Home
Delphi 2005, RAD Studio 2007, MASM32, FASM, SharpDevelop 3.0
|
Verfasst: Mi 13.02.08 21:54
_________________ Religionskriege sind nur Streitigkeiten darüber, wer den cooleren imaginären Freund hat
|
|
Silas
Beiträge: 478
Windows XP Home
Delphi 2005, RAD Studio 2007, MASM32, FASM, SharpDevelop 3.0
|
Verfasst: So 17.02.08 17:09
So, die neue Version 2.2 ist fertig!
[*] Die Lese- und Schreibmethoden für die Datei arbeiten nun intern mit Streams
[- ] Die SaveAs-Methode fällt weg, dafür akzeptiert Save nun einen Dateinamen-Parameter
[+] Create kann nun auch mit Streams aufgerufen werden
[+] Save kann nun in Streams speichern
[+] Bei ReadBinary kann nun auch der erste Parameter weggelassen werden, das hatte ich vergessen.
[*] Die Unit ist noch ein bisschen schneller geworden , weil ich für das Einlesen eine Stringliste verwendet hab, die den Vorteil bietet, dass die ganze Datei auf einmal gelesen wird.
(Download im ersten Posting.)
Und es gibt einen neuen Speedtest. Beim Auslese-Test wird nun vorher überprüft, ob der Wert auch existiert. Hier macht sich die Funktion des leztzen Zugriffs deutlich bemerkbar: FastIniFiles ist hier nun bei allen Dateien (klein, mittel, groß) ca. 100 mal schneller als TMemIniFile Außerdem ist in den verschiedenen Dateien auch die Anzahl der Einträge pro Sektion anders. Beim Einlesen liegt TMemIniFile logischerweise weiterhin vorne und ist dort ca. doppelt so schnell.
Das Ergebnis steht nun im ersten Posting, wo ihr den Speedtest auch runterladen könnt. Vorsicht, die neue Version braucht ziemlich viel Zeit, auf meinem (1 x 1.4GHz-) Rechner hat er eine Viertelstunde gedauert.
_________________ Religionskriege sind nur Streitigkeiten darüber, wer den cooleren imaginären Freund hat
Zuletzt bearbeitet von Silas am Sa 29.03.08 15:45, insgesamt 1-mal bearbeitet
|
|
alzaimar
Beiträge: 2889
Erhaltene Danke: 13
W2000, XP
D6E, BDS2006A, DevExpress
|
Verfasst: Di 19.02.08 22:35
Silas hat folgendes geschrieben: | Und es gibt einen neuen Speedtest. Beim Auslese-Test wird nun vorher überprüft, ob der Wert auch existiert. Hier macht sich die Funktion des leztzen Zugriffs deutlich bemerkbar: FastIniFiles ist hier nun bei allen Dateien (klein, mittel, groß) ca. 100 mal schneller als TMemIniFile |
Also das ist Selbstbetrug. Du testest doch so, das Du einen Wert 1000x liest. Und wenn du das dann optimierst, ist es ja wohl logisch, das dein 'SpeedTest' so ein Ergebnis bringt. Überlege Dir lieber, wie eine Ini-Datei im allgemeinen benutzt wird. Imho werden Werte zufällig gelesen und geschrieben, und nicht 10000x der gleiche Wert.
Bei der Gelegenheit wäre es interessant, den Quelltext von deinem Speedtest zu veröffentlichen. Mal sehen, wie TBigIni da abschneidet.
_________________ Na denn, dann. Bis dann, denn.
|
|
Silas
Beiträge: 478
Windows XP Home
Delphi 2005, RAD Studio 2007, MASM32, FASM, SharpDevelop 3.0
|
Verfasst: Mi 20.02.08 14:47
Das habe ich ja nicht optimiert. Der Geschwindigkeitsvorteil von FastIniFiles liegt zwischen ValueExists und ReadValue, und nicht zwischen zwei Lesevorgägen. ValueExists sucht den Wert immer neu, egal auf welchen vorher zugegriffen wurde. Das ist von praktischem Nutzen, weil man zumindest wenn man sauber programmiert, überprüfen sollte, ob ein Wert vorhanden ist, bevor man ihn benutzt. Die Unit ist hier bei 1000 verschiedenen Werten genauso schnell wie bei 1000 gleichen (zumindest relativ zu TMemIniFile, weil die Dateigröße ja steigen würde).
Der Quelltext liegt dem Speedtest, den du im ersten Posting runterladen kannst, schon bei.
_________________ Religionskriege sind nur Streitigkeiten darüber, wer den cooleren imaginären Freund hat
|
|
alzaimar
Beiträge: 2889
Erhaltene Danke: 13
W2000, XP
D6E, BDS2006A, DevExpress
|
Verfasst: Mi 20.02.08 17:26
silas: Ash on my Haupt.
_________________ Na denn, dann. Bis dann, denn.
|
|
Silas
Beiträge: 478
Windows XP Home
Delphi 2005, RAD Studio 2007, MASM32, FASM, SharpDevelop 3.0
|
Verfasst: Sa 29.03.08 15:45
Moin zusammen!
Es gibt (mal wieder) ein "Zwischenrelease" zum "großen" FastIniFiles 3.0, bei dem Unicode und Kommentare implementiert sein werden. 3.0 ist schon recht weit, aber noch lange nicht fertig. Diese Version ist daher haupsächlich ein Bugfixrelease.
Zusammen mit diesem Release habe ich auch Versionsnummern für die Unit eingeführt.
Neue Version 2.3
[+] Es gibt nun ReadValueDef-Methoden für alle Lesevorgänge , die bei einem nichtexistierenden Wert oder einem Konvertierungsfehler einen Defaultwert zurückgeben
[*] Ein Bug, der u.U. das schreiben einer nichtexistierenden Datei verhinderte, wurde behoben
[*] Ein weiterer Bug, der u.U. das korrekte Lesen eines Strings verhinderte, wurde ebenfalls behoben
Ich freu' mich natürlich weiterhin über Feedback
_________________ Religionskriege sind nur Streitigkeiten darüber, wer den cooleren imaginären Freund hat
|
|
Silas
Beiträge: 478
Windows XP Home
Delphi 2005, RAD Studio 2007, MASM32, FASM, SharpDevelop 3.0
|
Verfasst: Sa 05.04.08 19:57
So, da ist sie: Version 3.0
[+] Der Parser speichert nun Kommentare sowie Leerzeilen zurück
[*] Der Code wurde ein wenig überarbeitet
[+] Der Quelltext hat die 1000-Zeilen-Marke überschritten
Die Unicode-Unterstützung konnte ich leider noch nicht fertigstellen, da es noch ein Problem mit Heikos Unicode-Unit gibt. Die wichtigste Änderung ist aber geschehen, deswegen denke ich, 3.0 ist gerechtfertigt.
Dafür habe ich mir aber "Typsicherheit" (a la name:type=value) in mein TODO geschrieben. Das wäre die erste Veränderung, die den INI-Standard "sprengen" würde, mal sehen, wie ich das implementiere
_________________ Religionskriege sind nur Streitigkeiten darüber, wer den cooleren imaginären Freund hat
|
|
Gahero
Beiträge: 193
Win Vista HP 64bit
Delphi 2007 Pro
|
Verfasst: So 06.04.08 21:44
Ich bin leider noch nicht dazu gekommen, sie in mein Projekt einzubauen, hab ne ganze Menge anderes Zeug um die Ohren im Moment, aber demnächst werde ich das wohl angehen.
Meinen Respekt haste, weiter so... Wenn das Teil demnächst mehr sinnvolle und vorallem neue Features hat, die man nicht standardmäßig hat, wirds vllt auch mehr Leute interessieren die hier posten...
|
|
Silas
Beiträge: 478
Windows XP Home
Delphi 2005, RAD Studio 2007, MASM32, FASM, SharpDevelop 3.0
|
Verfasst: Mo 07.04.08 14:39
Gahero hat folgendes geschrieben: | Meinen Respekt haste, weiter so... |
Vielen Dank!
Gahero hat folgendes geschrieben: | Wenn das Teil demnächst mehr sinnvolle und vorallem neue Features hat, die man nicht standardmäßig hat, wirds vllt auch mehr Leute interessieren die hier posten... |
Freilich bemühe ich mich immer, neue Features einzubauen (wenn mir welche einfallen). Das Problem ist nur: Wenn mir niemand Vorschläge macht, was ich denn verbessern könnte, dauert es natürlich wesentlich länger, bis es etwas neues gibt.
_________________ Religionskriege sind nur Streitigkeiten darüber, wer den cooleren imaginären Freund hat
|
|
Gahero
Beiträge: 193
Win Vista HP 64bit
Delphi 2007 Pro
|
Verfasst: So 27.04.08 10:57
Habe jetzt endlich mal angefangen die Unit in mein Proj einzubauen.
Ich benutzte folgenden Code für meine Sprachdateien: (nur ein Auszug, der Rest ist ähnlich aufgebaut)
Delphi-Quelltext 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29:
| with TFIniFile.Create(ExtractFilePath(ParamStr(0)) + 'data/lang/lang_new.ini') do begin
for i := 1 to Frm.ComponentCount - 1 do begin
compo := Frm.Components[i];
if (compo is TLabel) then begin Entersection('TLabel'); WriteString((compo as TLabel).Name, (compo as TLabel).Caption); end;
if (compo is TBitBtn) then begin Entersection('TBitBtn'); WriteString((compo as TBitBtn).Name, (compo as TBitBtn).caption); end;
end;
Free;
end; |
Nachdem ich den Code für FastIniFile umgebaut habe, bringt er mir allerdings jedes Mal, wenn ich den Code oben aufrufe folgenden Fehler:
Zugriffsverletzung. (in der Zeile 621 " if Length(Value) > 0 then begin" Prozedure Save) Vorher mit TIniFile hat noch alles geklappt. Ist mein Code falsch oder hab ich nen Bug gefunden?
|
|
Silas
Beiträge: 478
Windows XP Home
Delphi 2005, RAD Studio 2007, MASM32, FASM, SharpDevelop 3.0
|
Verfasst: So 27.04.08 19:41
Moin Gahero,
werde mir das Problem morgen mal ansehen...
Bist du sicher, dass du die letzte Version (3.0, vom 5. April) verwendest? Ich kann mich dunkel daran erinnern, so etwas gefixt zu haben. Dein Quelltext an sich ist soweit fehlerfrei (und der Fehler tritt ja in meiner Unit auf).
_________________ Religionskriege sind nur Streitigkeiten darüber, wer den cooleren imaginären Freund hat
|
|
Gahero
Beiträge: 193
Win Vista HP 64bit
Delphi 2007 Pro
|
Verfasst: So 27.04.08 19:54
Hi,
habe die neuste Version 3.0. Ich habe oben auch noch den ersten kommentierten Code ausprobiert, der klappt ohne Probleme...
|
|
Silas
Beiträge: 478
Windows XP Home
Delphi 2005, RAD Studio 2007, MASM32, FASM, SharpDevelop 3.0
|
Verfasst: Mo 28.04.08 21:12
Ich habe den Bug gefunden und soweit behoben, allerdings ist er bei mir an einer anderen Stelle aufgetreten (was u.U. mit der Bereichsprüfung zusammenhängt).
Für diesen minimalen Fix spare ich mir eine Versionsnummer, sie ist weiterhin 3.0.
Die Projekt-Zip ist aktualisiert, du kannst sie im ersten Posting runterladen.
_________________ Religionskriege sind nur Streitigkeiten darüber, wer den cooleren imaginären Freund hat
|
|
Gahero
Beiträge: 193
Win Vista HP 64bit
Delphi 2007 Pro
|
Verfasst: Di 29.04.08 12:19
Ok, also mit der gefixten Version geht es ohne Probleme. Vielen Dank für das schnelle Update!
|
|
Regan
Beiträge: 2157
Erhaltene Danke: 72
Java (Eclipse), Python (Sublimetext 3)
|
Verfasst: Do 08.05.08 19:59
Silas hat folgendes geschrieben: | Freilich bemühe ich mich immer, neue Features einzubauen (wenn mir welche einfallen). Das Problem ist nur: Wenn mir niemand Vorschläge macht, was ich denn verbessern könnte, dauert es natürlich wesentlich länger, bis es etwas neues gibt. |
Dann versuch ich hier mal meine Vorschläge mit einzubeziehen: Wie wäre die Funktion, dass, wenn man eine Sektion geöffnet hat, man alle Werte auslesen kann.
Ansonsten funktioniert deine Unit sehr gut. Ich bin voll und ganz zufrieden .
|
|
Silas
Beiträge: 478
Windows XP Home
Delphi 2005, RAD Studio 2007, MASM32, FASM, SharpDevelop 3.0
|
Verfasst: Do 08.05.08 22:36
Regan hat folgendes geschrieben: | Wie wäre die Funktion, dass, wenn man eine Sektion geöffnet hat, man alle Werte auslesen kann. |
Gute Idee. Was hast du dir denn so als Ziel fürs Auslesen vorgestellt? Eine Stringlist (bzw. ein TStrings) oder eher ein String- oder gar ein Variant-Array?
Vielleicht könnte man in dieser Methode auch noch eine Filterfunktion einbauen.
Regan hat folgendes geschrieben: | Ansonsten funktioniert deine Unit sehr gut. Ich bin voll und ganz zufrieden . |
Vielen Dank, freut mich.
_________________ Religionskriege sind nur Streitigkeiten darüber, wer den cooleren imaginären Freund hat
|
|
Regan
Beiträge: 2157
Erhaltene Danke: 72
Java (Eclipse), Python (Sublimetext 3)
|
Verfasst: Fr 09.05.08 10:58
Silas hat folgendes geschrieben: | Regan hat folgendes geschrieben: | Wie wäre die Funktion, dass, wenn man eine Sektion geöffnet hat, man alle Werte auslesen kann. | Gute Idee. Was hast du dir denn so als Ziel fürs Auslesen vorgestellt? Eine Stringlist (bzw. ein TStrings) oder eher ein String- oder gar ein Variant-Array?
Vielleicht könnte man in dieser Methode auch noch eine Filterfunktion einbauen. |
Das würde ich eigentlich dir überlassen. Aber eine StringList mit den Namen würde mir eigentlich schon zureichen.
|
|
|