Große strukturierte Textdateien laden - immer langsamer

[DeddyH]

Meinst Du StrPCopy?

[himitsu]

Hab's gefunden (in falscher Unit gesucht )

StrNew, welches man allerdings nur mit StrDispose wieder freigeben kann (es sei denn man rechnet die kranke Längenangabe raus)

Zitat von DeddyH:

Meinst Du StrPCopy?

Hmmm, nicht ganz ... das kopiert ja nur, aber reserviert keinen Speicher.
Ich mein eher sowas sie DupStr/StrDup aus C++.

Nja, aber StrLCopy (weil ja nicht der ganze String kopiert werden soll), zusammen mit einem GetMem würde sich gut in einer Funktion machen.

Delphi-Quellcode:

function DupStr(str: PAnsiChar; MaxLen: NativeInt = -1): PAnsiChar; override;  // MaxLen incl. #0
function DupStr(str: PWideChar; MaxLen: NativeInt = -1): PWideChar; override;

function DupStr(str: PAnsiChar; MaxLen: NativeInt = -1): PAnsiChar;
begin
  if MaxLen = 0 then
    Exit(nil);
  if MaxLen < 0 then
    MaxLen = StrLen(str) + 1;
  Result := GetMemory(MaxLen * SizeOf(str^));
  try
    StrLCopy(Result, str, MaxLen);    
  finally
    FreeMemory(P);
  end;
end;

function DupStr(str: PWideChar; MaxLen: NativeInt = -1): PWideChar;
...

NewStr und Dispose für PChars (man darf nur nicht vergessen, daß Delphi dort noch eine Längenangabe drin versteckt)
SetString = von PChar zu String
DupStr = von PChar/String zu PChar

[friedemann2009]

Abend zusammen,

wow, - da hab ich ja ne Diskussion losgetreten.. Vielen Dank für die vielen Anregungen! Ich versuche mal die Möglichkeiten für eine Optimierung zu sortieren:

- Ohne Pointer: soviel POS wie möglich raus, Stringlist möglichst nur einmal durchlaufen, ggf. kleinere Puffer bilden.

-> Das war bisher in etwa auch mein Ansatz. Das Problem ist dabei aber die Datencodierung a la 'Quasi'-XML, also mit Anfangs- und Endtag, fortlaufend, Baumstruktur. Bisher habe ich noch nicht mit fertigen XML-Parsern gearbeitet.

- Mit Pointern: Vielen Dank für die Code-Bsp. Ich muss aber leider gestehen, dass ich sie nicht wirklich verstehe. Mir ist wohl immer noch nicht die Logik klar, mit der man "Pointer verschieben" kann u.ä. Ohne Pointer, zB bei Strings ist mir klar: Ich kann mit einem Index und einem Count Teile eines Strings kopieren, löschen etc, quasi Intervalle herausschneiden und in einen neuen Topf gegeben und weiterverarbeiten. Wie soll das bei Pointern gehen? Wie kann ich da 'Intervalle' von Daten definieren, wenn ich doch nur mit EINEM Zeiger auf EINEN 'Punkt' (also z.B. eine ganze Variable im Speicher) verweise? Bräuchte ich - für Intervalle wie '234' in '12345' nicht zwei Pointer? Da steh ich aufm Schlauch..

- Streams: Das scheint mir die naheliegendste, weil auch gerade am einfachsten umzusetzende Lösung zu sein. Die Reihenfolge der Datenspeicherung/-ladung ist klar. Ob das dann wirklich schneller wird, weiß ich noch nicht. Muss ich ausprobieren. Es dürften damit aber einige POSes entfallen.

Falls noch jemand einen Tipp zum Pointer-Verständnis hat (gerne auch am Bsp. von jaenicke), würde ich mich freuen.

Ansonsten nochmal herzliches Dankeschön und einen schönen Sonntagabend wünscht Euch
frieder

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