Effizientes Einlesen und Verarbeiten von Textdatei

[Dalai]

Hallo *.*.

Gegeben ist eine Textdatei, konkret im PEM-Format (BASE64 codiert). Ziel ist es, alle Blöcke dieser Datei einzulesen in ein Byte-Array - letztlich muss jeder Block in eine CERT_BLOB-Struktur. Bisher mache ich das folgendermaßen:

Delphi-Quellcode:

procedure NameNotRelevant;
var
  Lsl: TMyStringList;
  LidxH, LidxF: integer;
  Lstr: string;
begin
    Lsl:= TMyStringList.Create;
    try
      Lsl.LoadFromFile(FFileName);
      repeat
          LidxH:= Lsl.IndexOf(PEM_HEADER);
          LidxF:= Lsl.IndexOf(PEM_FOOTER);
          if LidxH < 0 then
            NameNotRelevant2(Lstr)
          else begin
            Lstr:= Trim(Lsl.StringsBetween(LidxH+1, LidxF-1));
            NameNotRelevant2(Lstr);
            Lsl.DeleteMultiple(LidxF-LidxH+1, LidxH);
          end; 
      until LidxH < 0;
    finally
      Lsl.Free;
    end;
end;

procedure NameNotRelevant2(const ACertStr: string);
var
  Lbin: TBytes;
  Lblob: CERT_BLOB;
begin
    if Length(ACertStr) = 0 then Exit;
    Lblob.cbData:= (Length(ACertStr)) * SizeOf(Char);
    SetLength(Lbin, Lblob.cbData);
    Move(ACertStr[1], Lbin[0], Lblob.cbData);
    Lblob.pbData:= LPByte(Lbin);
    // Do something with Lblob

(*    GetMem(Lblob.pbData, Lblob.cbData+1);
    try
      Move(ACertStr[1], Lblob.pbData, Lblob.cbData);
    finally
      FreeMem(Lblob.pbData);
    end;*)
end;

Die Methoden StringsBetween() und DeleteMultiple() hab ich ergänzt, und die Namen sollten selbsterklärend sein, aber sicherheitshalber hier noch deren Deklaration und Inhalt:

Delphi-Quellcode:

function TMyStringList.StringsBetween(AIndexFrom, AIndexTo: integer): string;
var
  i: integer;
begin
    Result:= '';
    if (AIndexFrom < 0) OR (AIndexTo >= Self.Count) then
        Exit;
    for i:= AIndexFrom to AIndexTo do
        Result:= Result + Self.Strings[i];
end;

function TMyStringList.DeleteMultiple(ACount: integer; AIndex: integer = 0): integer;
var
  i: integer;
begin
    Result:= -1;
    if (AIndex < 0) OR (AIndex >= Self.Count) then
        Exit;
    if (ACount >= Self.Count) then begin
        Result:= Self.Count;
        Clear;
    end else begin
        for i:= 1 to ACount do begin
            Self.Delete(AIndex);
            Inc(Result);
        end;
    end;
end;

Irgendwie finde ich die Sache ineffizent. Daher folgende Fragen:

1. Kann man die Verarbeitung der Datei anders gestalten, beispielsweise mit einem Stream, und wenn ja, wie suche ich in einem solchen nach einem bzw. mehreren bestimmten Strings?
2. Der Zwischenschritt über TBytes (= array of Byte) ist meiner Meinung nach unnötig. Irgendwie bin ich aber zu blöd, direkt auf Lblob.pbData den Speicher zu reservieren, die Bytes des Strings mit Move dorthin zu kopieren, und anschließend den Speicher mit FreeMem wieder freizugeben, ohne dass es knallt (siehe auskommentierter Teil). Ja, ich weiß, dass Move die Adresse des Zielspeichers ändert und es deshalb knallt. Wie kann ich denn sonst die Bytes des Strings dorthin übertragen?

Grüße
Dalai

[freimatz]

Hallo,
inwiefern ineffizient? Vermutest Du oder hast Du gemessen? Was die Laufzeit betrifft denke ich, dass LoadFromFile die allermeiste Zeit benötigt.

Deinen Code verstehe ich nicht, aber das "until Lidx < 0;" kommt mir komisch vor. Lidx kommt sonst nicht vor.

[Sinspin]

Zitat von Dalai:

Ja, ich weiß, dass Move die Adresse des Zielspeichers ändert und es deshalb knallt.

Was? Nee, noch nie gehört.
Ich denke dann gibst Du bei Move einen Parameter falsch an.

[Neutral General]

Delphi-Quellcode:

procedure NameNotRelevant2(const ACertStr: string);
var
  Lbin: TBytes;
  Lblob: CERT_BLOB;
begin
    if Length(ACertStr) = 0 then Exit;
    Lblob.cbData:= (Length(ACertStr)) * SizeOf(Char);
    SetLength(Lbin, Lblob.cbData);
    Move(ACertStr[1], Lbin[0], Lblob.cbData);
    Lblob.pbData:= LPByte(Lbin);

Man sieht dass du den Code etwas gekürzt/vereinfacht hast um ihn hier zu posten von daher trifft meine Kritik unter Umständen nicht zu, aber

Delphi-Quellcode:

.
Lblob.pbData:= LPByte(Lbin);

Wird nur innerhalb dieser Methode funktionieren. Wird auf den CERT_BLOB außerhalb dieser Methode zugegriffen ist das TBytes Array nicht mehr gültig und lBlob.pbData zeigt auf ungültige Daten.
So geht der direkte Weg ohne TBytes:

Delphi-Quellcode:

procedure NameNotRelevant2(const ACertStr: string);
var
  Lblob: CERT_BLOB;
begin
    if Length(ACertStr) = 0 then Exit;
    Lblob.cbData:= (Length(ACertStr)) * SizeOf(Char);
    GetMem(Lblob.pbData, Lblob.cbData);
    Move(ACertStr[1], Lblob.pbData^, Lblob.cbData);

Du musst dann aber dran denken lBlob.pbData mit FreeMem freizugeben, wenn der BLOB nicht mehr gebraucht wird.

EDIT: Ich weiß zwar nicht was du da machst, aber solltest du den Base64 String nicht vorher decoden und dann erst dem Blob zuordnen?

[TiGü]

Zitat:

Der Zwischenschritt über TBytes (= array of Byte) ist meiner Meinung nach unnötig. Irgendwie bin ich aber zu blöd, direkt auf Lblob.pbData den Speicher zu reservieren, die Bytes des Strings mit Move dorthin zu kopieren, und anschließend den Speicher mit FreeMem wieder freizugeben, ohne dass es knallt (siehe auskommentierter Teil). Ja, ich weiß, dass Move die Adresse des Zielspeichers ändert und es deshalb knallt. Wie kann ich denn sonst die Bytes des Strings dorthin übertragen?

Falls es dir irgendwie eine Hilfe ist, aber in der HTTP-Request-Klasse der höheren Delphi-Versionen in der Unit System.Net.HttpClient.Win wird auch mit einem Stream (FClientCertificate) der Umweg über ein dynamisches TBytes-Array gegangen.

Delphi-Quellcode:

procedure TWinHTTPRequest.SetWinCertificate;
var
  LStore: HCERTSTORE;
  LCertContext: PCCERT_CONTEXT;
  LBlob: CRYPT_DATA_BLOB;
  LBytes: TBytes;
begin
  if (FClientCertPath = '') and (FClientCertificate = nil) then
    Exit;

  if FClientCertPath <> '' then
    LStore := CertOpenStore(PAnsiChar(CERT_STORE_PROV_FILENAME), X509_ASN_ENCODING or PKCS_7_ASN_ENCODING,
      0, CERT_STORE_OPEN_EXISTING_FLAG or CERT_STORE_READONLY_FLAG, PChar(FClientCertPath))
  else
  begin
    LBlob.cbData := FClientCertificate.Size; // <--- siehe von hier...
    SetLength(LBytes, LBlob.cbData);
    FClientCertificate.Position := 0;
    FClientCertificate.Read(LBytes, LBlob.cbData); 
    LBlob.pbData := PByte(@LBytes[0]); // <--- ...bis hier!
    LStore := PFXImportCertStore(@LBlob, PChar(FClientCertPassword), 0);
  end;
  if LStore = nil then
    raise ENetHTTPRequestException.CreateResFmt(@SNetHttpCertFileOpenError,
      [GetLastError, SysErrorMessage(GetLastError, TWinHttpLib.Handle)]);
  try
    LCertContext := CertFindCertificateInStore(LStore, X509_ASN_ENCODING or PKCS_7_ASN_ENCODING,
      0, CERT_FIND_ANY, nil, nil);
    if LCertContext = nil then
      raise ENetHTTPRequestException.CreateResFmt(@SNetHttpCertNotFoundError,
        [GetLastError, SysErrorMessage(GetLastError, TWinHttpLib.Handle)]);
    try
      WinHttpSetOption(FWRequest, WINHTTP_OPTION_CLIENT_CERT_CONTEXT,
        LCertContext, SizeOf(CERT_CONTEXT));
    finally
      CertFreeCertificateContext(LCertContext);
    end;
  finally
    CertCloseStore(LStore, 0);
  end;
end;

Delphi-Quellcode:

// mit der Definition aus Winapi.Windows
type
  _CRYPTOAPI_BLOB = record
    cbData: DWORD;
    pbData: PBYTE;
  end;
...
CRYPT_DATA_BLOB = _CRYPTOAPI_BLOB;

[Dalai]

Zitat von freimatz:

Vermutest Du oder hast Du gemessen?

Da ich aus der Vergangenheit hier im Forum weiß, dass Messen in sich ein komplexes Thema ist, habe ich nicht gemessen. Aber trotzdem dauert das Verarbeiten einer Datei mit 132 solcher Blöcke ca. 2 Sekunden (jedenfalls wenn es im externen Speicherlecksucher läuft). Wie gesagt, nicht besonders genau, weil lediglich mitgezählt.

Zitat:

Was die Laufzeit betrifft denke ich, dass LoadFromFile die allermeiste Zeit benötigt.

Das muss ich in der Tat mit dem Debugger noch genauer untersuchen, ob es wirklich am Laden liegt. Aber ich weiß, dass Strings in Bezug auf Ressourcen deutlich teurer sind als sonstige einfach Datentypen, vor allem weil ich ja nach und nach Zeilen aus der Stringliste lösche. Daher kann ich mir gut vorstellen, dass andere Wege effizienter sind.

Zitat:

Deinen Code verstehe ich nicht, aber das "until Lidx < 0;" kommt mir komisch vor. Lidx kommt sonst nicht vor.

Sorry, das kommt davon, wenn man Code für solche Fragen verkürzt. Hab's grade korrigiert.

Zitat von Sinspin:

Was? Nee, noch nie gehört.
Ich denke dann gibst Du bei Move einen Parameter falsch an.

Dest ist bei Move doch ein var -Parameter. Daraus schloss ich, dass dessen Adresse verändert werden kann. Was ist denn deiner Meinung nach falsch an dem auskommentierten Move-Aufruf?

Grüße
Dalai

[Dalai]

Zitat von Neutral General:

[...] aber

Delphi-Quellcode:

.
Lblob.pbData:= LPByte(Lbin);

Wird nur innerhalb dieser Methode funktionieren. Wird auf den CERT_BLOB außerhalb dieser Methode zugegriffen ist das TBytes Array nicht mehr gültig und lBlob.pbData zeigt auf ungültige Daten.

Ja, das ist mir klar. Die Variablen werden nur innerhalb dieser Methode verwendet.

Zitat:

So geht der direkte Weg ohne TBytes:

Delphi-Quellcode:

procedure NameNotRelevant2(const ACertStr: string);
var
  Lblob: CERT_BLOB;
begin
    if Length(ACertStr) = 0 then Exit;
    Lblob.cbData:= (Length(ACertStr)) * SizeOf(Char);
    GetMem(Lblob.pbData, Lblob.cbData);
    Move(ACertStr[1], Lblob.pbData^, Lblob.cbData);

Danke, das funktioniert tatsächlich. Warum muss Lblob.pbData dereferenziert werden? Was übersehe ich?

Zitat:

Du musst dann aber dran denken lBlob.pbData mit FreeMem freizugeben, wenn der BLOB nicht mehr gebraucht wird.

Deswegen steht ja das FreeMem bereits da .

Zitat:

EDIT: Ich weiß zwar nicht was du da machst, aber solltest du den Base64 String nicht vorher decoden und dann erst dem Blob zuordnen?

Das kommt darauf an, an welche Funktion man diesen CRYPT_BLOB übergibt. In diesem Fall überlasse ich das der Windows API, konkret der Funktion CryptQueryObject.

Grüße
Dalai

[BerndS]

Effizienter wäre es sicher, wenn das Auswerten der Stringlist ohne IndexOf und Delete gemacht würde. Das sind zusätzliche Speicheroperationen, die nicht nötig wären, wenn man es in etwas so machen würde.

Delphi-Quellcode:

var
  Lsl: TStringList;
  LidxH, LidxF: integer;
  Lstr, Line: string;
  I: Integer;
begin
    Lsl:= TStringList.Create;
    try
      Lsl.LoadFromFile(FFileName);
      LidxH := -1;
      LidxF := -1;
      Lstr := '';
      for I := 0 to lsl.Count -1  do
      begin
        Line := lsl[I].Trim;
        case IndexStr(Line, [PEM_HEADER, PEM_FOOTER]) of
          0: LidxH := I;
          1:
            if LidxH>=0 then
            begin
              NameNotRelevant2(Lstr);
              LidxH := -1;
              LidxF := -1;
              Lstr := '';
            end;
          else
           if LidxH >= 0 then
             Lstr := Lstr + Line;
        end;
      end;
    finally
      Lsl.Free;
    end;
end;

Es geht sicher auch, wie du es machst.
Ob diese Änderung aber schneller ist, kann ich ohne geeignete Daten nicht prüfen.
Um die Zeitdauer von bestimmten Operationen zu messen, werwende ich gerne GetTickCount. Das ist zwar nicht genau, aber man bekommt dadurch grob raus, wo es länger dauert.

[Neutral General]

Zitat von Dalai:

Danke, das funktioniert tatsächlich. Warum muss Lblob.pbData dereferenziert werden? Was übersehe ich?

procedure Move(const Source; var Dest; Count: NativeInt);
Wie du siehst sind für Source und Dest keine Datentypen angegeben.

Was dort intern passiert ist, dass in der Wahrheit immer ein Pointer dessen übergeben wird was du als Parameter angibst.
Im Prinzip wird bei Source und Dest ein unsichtbares "@" vor den übergebenen Wert gesetzt.

Das hier:
Move(ACertStr[1], Lblob.pbData^, Lblob.cbData)
ist unter der Haube letztendlich
Move(@ACertStr[1], @(Lblob.pbData^), Lblob.cbData) // Was wirklich übergeben wird

D.h. wenn du bei Lblob.pbData das ^ weglässt schreibt er die Daten nach @Lblob.pbData, was den Inhalt des Pointers selbst überschreibt statt den Speicher auf den der Pointer zeigt.
Durch das dereferenzieren bekommst du dann quasi sowas @(Lblob.pbData^) was sich wieder ausgleicht und ausgewertet Lblob.pbData ergibt wodurch dann tatsächlich dahin geschrieben wird, wo der Pointer hinzeigt, statt den Pointer selbst zu überschreiben.

Ich hoffe das war halbwegs verständlich (Erklären ist nicht immer so einfach )

[Uwe Raabe]

Zitat von BerndS:

Um die Zeitdauer von bestimmten Operationen zu messen, werwende ich gerne GetTickCount. Das ist zwar nicht genau, aber man bekommt dadurch grob raus, wo es länger dauert.

Genauere Zeiten und mindestens ebenso bequem bekommt man es mit TStopWatch aus System.Diagnostics:

Delphi-Quellcode:

var sw := TStopWatch.StartNew;
...
Writeln(sw.ElapsedMilliseconds);