Große strukturierte Textdateien laden - immer langsamer

[jaenicke]

Ja, du siehst das richtig was Pointer angeht. Ich habe z.B. immer einen Startpointer für den aktuellen Bereich und einen Laufpointer. Habe ich dann ein Element identifiziert, kopiere ich einfach ab dem Startpointer den String heraus. Die Länge bekomme ich durch die Differenz mit dem Laufpointer.

Auf diese Weise muss nur etwas kopiert werden, wenn ich auch etwas herauskopieren will.

Ein Beispiel kann ich erst morgen Abend liefern, wenn nötig.

[friedemann2009]

Ok, danke!

Ich habe mich jetzt dran gemacht und das ganze zunächst als FileStream / StringToStream zu lösen. Leider habe ich jetzt das Problem, dass offenbar die Strings falsch geschrieben und/oder gelesen werden: Wenn ich "True" schreibe, kommt zumindest (spätestens) beim Lesen ein "TrXX" (XX = komische Zeichen). Ich vermute, es ist ein Codierungsproblem (PChar usw.). Habe dahingehend schon im Forum gesucht, aber die Lösungsvorschläge dort (für D2009) haben nicht funktioniert.

Mein Code für das Speichern/Lesen der Strings und Integer:

Delphi-Quellcode:

Function StreamToString(aStream: TStream): string;
var
  Len: longint;
  tempstr: String;
begin
  aStream.Read(Len, SizeOf(Len));
  SetLength(tempStr, Len);
  aStream.Read(PChar(tempStr)^, Len);
  result:= tempStr;
end;

Function StreamToInteger(aStream: TStream): integer;
var
  tempint: integer;
begin
  aStream.Read(tempint, SizeOf(tempint));
  result:= tempint;
end;

//----------

Procedure StringtoStream(aStream: TStream; astring: string);
var
  len: longint;
begin
  len:= Length(astring);
  aStream.Write(len, Sizeof(Len));
  aStream.Write(PChar(aString)^, Len);
end;

Procedure IntegertoStream(aStream: TStream; aint: integer);
begin
  aStream.Write(aint, SizeOf(aint));
end;

Ich nutze Delphi XE3 - und die Strings sind von 0 Zeichen bis sehr große Datentabellen-Strings (und sollten eigentlich überall AnsiString sein).

Wenn ich anstelle von PChar einfach AnsiChar nehme, bekomme ich einen Error für ungültige Typumwandlung.

Danke und schöne Grüße,
frieder

[himitsu]

Dennoch nimm PAnsiChar und AnsiString.

String/PChar hat seit Delphi 2009 zwei Byte pro Zeichen und in deinen Dateien ist es aber nur mit 1 Byte pro Zeichen gespeichert.


Und was ist die "entgültige" Typumandlung?


PS: Bezüglich der Unicodeumsellung gibt es zahlreiche Threads und Tutorials.

Grundsätzlich kann man sagen, daß es deine eigene Schuld war, daß jetzt nichts mehr läuft, denn man sollte niemals dynamische Typen binär speichern/übertragen, sonsdern ausschließlich generische Typen, welche unveränderlich sind.
Das fing bei Unicode an, wo tring, Char und PChar sich veränderten und geht nun mit 64 Bit weiter.

[nuclearping]

@friedemann: Mal was gänzlich anderes. Warum benutzt du eigentlich nicht gleich eine ordentliche Datenbank, wie zB Firebird, um deine Sachen abzulegen?

[friedemann2009]

Zitat von nuclearping:

@friedemann: Mal was gänzlich anderes. Warum benutzt du eigentlich nicht gleich eine ordentliche Datenbank, wie zB Firebird, um deine Sachen abzulegen?

Ja, das wäre dann der nächste Schritt. Offen gesagt: Ich bin von Haus aus kein Programmierer, sondern Linguist, der sich seit 5 Jahren Lerning-by-doing durch Delphi schlägt und methodische Verfahren zur Sprach- und Imageanalyse entwickelt.. - Welche Code-Richtung meine Progs jeweils eingeschlagen haben, hing von meinen bisherigen Projekten, zufälligen Google-Treffern und Tipps hier aus dem Forum ab.. Eine DB war unter den Tipps bisland nicht

Zitat von himitsu:

Grundsätzlich kann man sagen, daß es deine eigene Schuld war, daß jetzt nichts mehr läuft, denn man sollte niemals dynamische Typen binär speichern/übertragen, sonsdern ausschließlich generische Typen, welche unveränderlich sind.

Ja, das merke ich gerade auch. Da fehlt mir eben das Basis-Wissen zur Entwicklung der unterschiedlichen Datentypen, sorry..

Habe AnsiChar einsetzen können, jetzt läuft alles.

- Durch das Abspeichern/Laden der Daten via Streams geht der Prozess insgesamt deutlich schneller.

Danke Euch allen für die Anregungen und Tipps, schöne Woche,
frieder

[himitsu]

Zitat von friedemann2009:

Ja, das merke ich gerade auch. Da fehlt mir eben das Basis-Wissen zur Entwicklung der unterschiedlichen Datentypen, sorry..

Mach dir nichts draus ... das haben die Meisten falsch gemacht, bzw. nicht gewusst/beachtet.

Wobei es auch anders kommen kann.
Bei 64 Bit war mal der Integer/Cardinal veränderlich und nun hat man den einfach eingefroren und einen neuen Typen erfunden.
Das gibt jetzt also beim Speichern/Laden/Übertragen weniger Problemem aber dafür dann im Programm, weil ganz Viele zwischen Pointer und Integer gecastet haben (was eigentlich auch gepaßt hätte), aber nun eben Datenverlust mit sich bringt, weil vom Pointer die Hälfte verloren geht.


PS: Ich versuche hier grade ein Projekt "eigentlich" auf 64 Bit zu portieren, aber was darin alles gemacht wurde ... da wird einem Schlecht.
z.B. wurden erstmal alle Warnungen deaktiviert. OK, die Meisten Warnungen sind nur String<>AnsiString-Warnungen, wo Delphi es aber automatisch npasst, aber dazwischen waren auch welche, wo Delphi nichts anpassen konnte. PChar<>PAnsiChar und dann wundert man sich, daß Einiges nicht geht
Also immer schön auf den Compiler hören.


Nja, einfacher hättest du es mit TReader/TWriter gehabt.
Das beachtet selbst das Format und speichert es sogar in der Datei mit ab, so daß man die Datei auch noch auslesen könnte, selbst wenn etwas nicht paßt.
Das kennst du z.B. von der DFM und wenn es gewisse Komponenten oder Property nicht mehr gibt.

[p80286]

@Himitsu
nun laß mal gut sein. Auch wenn Du Recht hast, das "Typ-Problem" ist doch hausgemacht.
Nimm doch einfach den "integer". Das ist eine ganze Zahl mit Vorzeichen, und je nach Compiler/Rechner 8/16/32/64 Bit breit das kann man doch nicht ernst nehmen. Mit Rücksicht auf die lernschwächeren unter uns ist alles Integer und Char ?
Solange in den Hanbüchern noch diese Verdummung betrieben wird wirst Du auch immer die gleichen Probleme haben.
(was ist gegen word16,word32,word64 einzuwenden?)

Gruß
K-H

[Sherlock]

Es scheinen ja hier mehrere Probleme eine schöne Summe von Performance zu kosten. Ein Teilproblem ist sicherlich die Verwendung von Stringlisten. Wir hatten auch Dateien auszulesen, und haben dabei numerische "Tags" als Strings eingelesen und als Sortierschlüssel für die Stringlisten verwendet. Stringvergleiche sind aber langsam...so richtig langsam. Deshalb sind wir auf Arrays umgestiegen in denen besagte "Tags" wirklich numerisch vorliegen, das flitzt jetzt erheblich schneller. Wenn also Deine Listen sortiert sind/sein müssen, dann empfehle ich von Strings als Sortierkriterien wegzugehen, oder einen effizenteren Vergleichsalgorithmus zu finden.

Sherlock

[p80286]

Solange wir nicht wissen, wie der Source wirklich aussieht, sind das alles nur gutgemeinte Ratschläge.
Und der Unterschied zwischen gut gemeint und gut gemacht ist bekanntlich gewaltig.

Gruß
K-H