DLL Performance allgemein

[markus888]

Liebe Delphi Community!

Ich entwickle in MS Accees mit VBA und beschäftige mich seit wenigen Tagen mit Delphi.
Hauptzweck ist bisher das Schreiben von DLL um die Performance innerhalb von VBA zu verbessern
und die Möglichkeiten zu erweitern.

Ich habe einige kleine Scripte erstellt und Performance Vergleiche angestellt.
Ist grundsätzlich zu erwarten, dass ich mit Delphi DLL ähnliche Performace wie mit WinAPI erreichen kann?

Hier zwei Scripte mit dem selben Ziel. Die Suche nach einer Chargruppe in einem String und das Ersetzen durch ein anderes Zeichen.
Hier ein Teil der ersten Funktion, die mittels API StrCSpnW das Vorkommen im String sucht:
Übergeben werden aus VBA drei StringsPointer und eine Pointer auf einen StringPointer für die Rückgabe an VBA.

Code:

function ReplCharGroup(Text, CharGroup, Repl:PWideChar; ResString:PInteger):integer;stdcall;
var
  lText, lChars, lRepl, f, lMem:Integer;
  p, r, rp:PWideChar;
begin
  lChars:=BstrLen(CharGroup^);
  lText:= BstrLen(Text^);
  lRepl:= BstrLen(Repl^);
  result:=0;

  //kein Text
  if ltext = 0 then Exit(1);

  if lChars = 0 then Exit(2);

  f:=StrCSpnW(Text, CharGroup);
  if f=lText then begin
    SysReAllocStringLen(ResString^, Text^, lText);
    Exit;
  end;

  if lRepl=1 then begin
    SysReAllocStringLen(ResString^, Text^, lText);
    p:=PWideChar(ResString^);

    repeat
      inc(p, f);
      p^:=Repl^;
      inc(p);
      dec(lText, f+1);
      f:=StrCSpnW(p, CharGroup);
    until lText = f ;


  end

Hier eine Variante die direkt nach dem Vorkommen sucht:

Code:

function CharInGroup(var Text:PWideChar; CharGroup:PWideChar; const lText, lChars :Integer; Position:Integer):integer;inline;
var t,c,r:integer;
begin
  for t := Position to lText do begin
    for c := 1 to lChars do begin
      if chargroup^ = text^ then
        exit(t)
      else
        inc(chargroup);
    end;
    inc(Text);
    dec(Chargroup, lChars);
  end;
  result:=0;
end;

function ReplCharGroup2(Text, CharGroup, Repl:PWideChar; ResString:PInteger):integer; stdcall;
var
  lText, lChars, lRepl, f, fOld, lMem:Integer;
  p, r, rp:PWideChar;
begin
  lChars:=BstrLen(CharGroup^);
  lText:= BstrLen(Text^);
  lRepl:= BstrLen(Repl^);
  fold:=1;
  result:=0;

  //kein Text
  if ltext =  0 then Exit(1);
  if lChars = 0 then Exit(2);

  if lRepl=1 then begin
    SysReAllocStringLen(ResString^, Text^, lText);
    p:=PWideChar(ResString^);
    f:=CharInGroup(p,CharGroup, lText, lChars,fold);
    if f=0 then Exit;
    repeat
      p^:=Repl^;
      fold:=f+1;
      inc(p);
      f:=CharInGroup(p,CharGroup, lText, lChars,fold);
    until f=0;

  end

API Deklarationen:

Code:

 Function StrCSpnW (StrPtr, Charset:PWideChar):Integer; stdcall;external 'Shlwapi';
  Function SysReAllocStringLen (var BSTR, StrPtr; Letters: Integer):LongWord; stdcall;external 'OleAut32';
  Function BstrLen (var StrPtr):integer;stdcall;external 'oleaut32' name 'SysStringLen';

Es funktionieren beide Codes ohne Probleme und wie gesagt es sind nur Teile der Funktion (aber vollständig, was das ersetzen durch ein Zeichen anbelangt).
Allerdings steigt der Zeitbedarf der selbst geschriebene Suche exponential gegenüber der Suche mittels API.

Kann ich die Performance von CharInGroup erhöhen?

Danke für Eure Mühe.

LG Markus

[Bernhard Geyer]

Zitat:

Zitat von markus888 (Beitrag 1421815)

Ich entwickle in MS Accees mit VBA und beschäftige mich seit wenigen Tagen mit Delphi.
Hauptzweck ist bisher das Schreiben von DLL um die Performance innerhalb von VBA zu verbessern
und die Möglichkeiten zu erweitern.

Soll das was größeres werden?
Dann schmeiße am besten alles gleich wieder weg.
Access für "kleine Hilfstools" geeignet, aber wenn es darüber hinausgeht eine absolute Katastrophe.

Ich kenne auch denn Fall das man mittels DLLs und ActiveX seine bisherige Implementierung retten wollte.
Hat das System auch nur verkompliziert

[markus888]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1421820)

Soll das was größeres werden?

Hallo Bernhard!
Grundsätzlich weiß ich sehr genau was Access zu leisten vermag und wo es seine Stärken und Schwächen hat.

Es soll auch nichts größeres werden, es geht mir darum Erfahrung mit Delphi zu sammeln und die Grundlagen besser zu verstehen.
Womöglich werde ich künftig auch fallweise mit Delphi entwickeln, da es mir ganz gut gefällt.

In dem konkreten Fall, wollte ich die Performance testen und war doch etwas enttäuscht, dass der doch sehr simple Code in Delphi so viel langsamer arbeitet wie die API Funktion.
Die Frage ist, woran das liegt, dass die API so viel schneller arbeitet, obwohl bei der API noch der Overhead der Prüfung auf das Stringende gegeben ist.

Daher wäre es schön, wenn du etwas zu meiner Frage beitragen könntest - zumal ich so gut wie keine Erfahrung mit Delphi habe -, aber ich kann lesen, daher ich es auch kein Problem einen Code zu schreiben. :-D

[MichaelT]

Der allgemeine Teil.

Tue mir den Bernhard nicht schimpfen.

Dein Ansinnen ist schon ok.

a)
Delphi Performance. Als die Bärte der Delphi Programmierer noch nicht so lange und schon gar nicht so grau waren wurde der Inline Assembler als High-Level Assembler verwendet um die Teile die der Compiler nicht (passend) optimierte zu beschleunigen.

Der Verdacht drängt sich aus, dass es in der Windows API nicht viel anderes zugeht.

b)
Der andere Stream war in C und C++ geschriebene DLLs einzubinden. Du hast unter Win32 durch die Optimierung des C/C++ Compiler und insbesondere auch der Optimierung entlang der Floating Point Modelle ein paar Trümpfe in der Hand. Auf diese Speed kommst du nicht hin, aber dem war nie so - siehe a).

Delphi ist kein C Compiler mit Pascal Syntax. Allein hat man früher sehr schlanke Executables gehabt bei der der Code potentiell eher noch in den Cache gepasst hat. So gut kann ein Compiler gar nicht optimieren um dies zu kompensieren.

Du probierst b).

Prinzipiell. Die Idee die DLL zu verwenden um zu beschleunigen macht schon Sinn. Es zahlt sich heute nicht mehr aus.

Ich verstehe nicht warum du nicht einfach bspw. Funktionen aus der Familie und um WideStringReplace nimmst.

Mit interessiert Active X nicht (mehr). Ich bin mir nicht ganz sicher ob du den ResString freigibst. Einen Integer Pointer kennt der Garbage Collector genausowenig wie eine PWideString er klarerweise nicht als Zeichenkette erkennt.

Ich suche mal eine Variante unter Einbindung der ActiveX unit zum Laufen zu bringen.

Zitat:

Zitat von markus888 (Beitrag 1421815)

Liebe Delphi Community!

Ich entwickle in MS Accees mit VBA und beschäftige mich seit wenigen Tagen mit Delphi.
Hauptzweck ist bisher das Schreiben von DLL um die Performance innerhalb von VBA zu verbessern
und die Möglichkeiten zu erweitern.

Ich habe einige kleine Scripte erstellt und Performance Vergleiche angestellt.
Ist grundsätzlich zu erwarten, dass ich mit Delphi DLL ähnliche Performace wie mit WinAPI erreichen kann?

Kann ich die Performance von CharInGroup erhöhen?

Danke für Eure Mühe.

LG Markus

[DieDolly]

Zitat:

dass der doch sehr simple Code in Delphi so viel langsamer arbeitet wie die API Funktion.

Simpler Code muss nicht immer schnell sein.

Eine 50 Zeilen Procedur kann schneller sein als irgendein angeblich simpler Einzeiler.

[dummzeuch]

Irgendwie scheinen mir alle bisherigen Antworten an der Frage vorbei zu gehen:

Kann man von Delphi-DLLs die gleiche Performance erwarten wie von WinAPI-Funktionen?

Meiner Ansicht nach ist die Antwort: Meistens Ja, im Rahmen der Messgenauigkeit.

Es hängt natürlich stark davon ab, was genau man macht. Ich muss zugeben, dass ich den Sourcecode auf Anhieb nicht verstanden habe (aber ich habe auch nur grob drüber geschaut). Wenn es wesentlich langsamer ist als die entsprechende WinAPI-Funktion, würde ich eher auf eine ineffiziente Implementierung tippen als auf ein generelles Problem mit Delphi-DLLs.

Typische Fehler wären beispielsweise Funktionen, die einen String immer wieder von vorne lesen, z.B. Pos('a', s), also etwa dieser Code, um alle Vorkommen von 'a' durch 'x' zu ersetzen:

Delphi-Quellcode:

p := Pos('a', s);
while p > 0 do begin
  s[p] := 'x';
  p := Pos('a', s);
end;

Leider muss man im Zweifelsfall davon ausgehen, dass der Delphi-Compiler nicht immer den effizientesten Code erzeugt und dass auch die RTL nicht immer die effizienteste Implementation einer Funktion enthält. Aber wie oben geschrieben: Das ist relativ selten der Grund für ein Performance-Problem, der eigene Code ist viel häufiger der Grund.

[MichaelT]

Ergänzung. Es ist auch nicht ungewöhnlich, dass Windows API Aufrufe verwendet werden und die VCL ist voller Klassen die zumindest als Vorlage dienen diese zu kombinieren.

C/C++ Code in Delphi zu replizieren mit anderen Schlüsselwörtern bringt es nicht. Mal abseits der Optimierung der C/C++ Compiler an sich macht das der Compiler sowieso. Gegebenenfalls kann man auf dem Weg an der einen Stelle oder der anderen etwas optimieren. Das schon.

Zur Sache.

Wieviele Mio Aufrufe hast du?

Ich habe das ganze in einem Programm (nicht als DLL) mit WideString durchgezogen. Eine Mio. Aufrufe Dauern in etwa zwei Sekunden.

Das Handling der Speicheranforderung des ResString als PInteger müsste man sich mal anschauen.

In dem Forum gibt es Leute die bezüglich der Eigenheiten mehr wissen.

Du wirst schon gute Gründe gehabt haben sämltiche WideString Functions links liegen gelassen zu haben.

Zitat:

Zitat von markus888 (Beitrag 1421815)

Liebe Delphi Community!

Kann ich die Performance von CharInGroup erhöhen?

Danke für Eure Mühe.

LG Markus

[MichaelT]

Nicht ganz. (kein Bezug zu deiner Implementierung - die ist sowieso ok)

Die Funktionen macht eine Art StringReplace für WideString. Wenn der Ersetzungstext länger ist als 1 wird abgebrochen usw...

Der Code reimplemtiert mit Widestring pfeift dahin und wie im Original läuft der Code genauso. Ich habe eher den Verdacht, dass das Handling des ResString nicht hinhaut. Man sieht nirgends das Anfordern des Speichers und die Freigabe. Solange wir die nicht sehen können wir nicht viel sagen.

Was auf der VB Seite läuft kann ich auch nicht sagen.

---

Solange man nicht wie im puren C den String von vorne bis hintern Character für Character abklappert die aktuelle Adresse oder das Ende des Strings zurückgibt ist die Differenz zum Pascal String so groß nicht.

---

Delphi ist nicht in dem Sinne so wie Ada mit einem GCC backend. Aber zu glauben, dass eine Implementierung einer Funktion der MS heute langsam wäre.

---

Das mag es Mitte der 90er noch gegeben haben und spielte eine Rolle als die Prozessoren noch nicht mal 800 MHz hatten.

---

UNIX und bestimmt auch Windows haben bei den Low Level Funktionen puren Assembler laufen. Aber für eine Funktion die schon implementiert ist, ...

Zitat:

Zitat von dummzeuch (Beitrag 1421837)

Irgendwie scheinen mir alle bisherigen Antworten an der Frage vorbei zu gehen:

Kann man von Delphi-DLLs die gleiche Performance erwarten wie von WinAPI-Funktionen?

Meiner Ansicht nach ist die Antwort: Meistens Ja, im Rahmen der Messgenauigkeit.

Es hängt natürlich stark davon ab, was genau man macht. Ich muss zugeben, dass ich den Sourcecode auf Anhieb nicht verstanden habe (aber ich habe auch nur grob drüber geschaut). Wenn es wesentlich langsamer ist als die entsprechende WinAPI-Funktion, würde ich eher auf eine ineffiziente Implementierung tippen als auf ein generelles Problem mit Delphi-DLLs.

Typische Fehler wären beispielsweise Funktionen, die einen String immer wieder von vorne lesen, z.B. Pos('a', s), also etwa dieser Code, um alle Vorkommen von 'a' durch 'x' zu ersetzen:

Delphi-Quellcode:

p := Pos('a', s);
while p > 0 do begin
  s[p] := 'x';
  p := Pos('a', s);
end;

Leider muss man im Zweifelsfall davon ausgehen, dass der Delphi-Compiler nicht immer den effizientesten Code erzeugt und dass auch die RTL nicht immer die effizienteste Implementation einer Funktion enthält. Aber wie oben geschrieben: Das ist relativ selten der Grund für ein Performance-Problem, der eigene Code ist viel häufiger der Grund.

[markus888]

Danke erstmal für die Antworten.

Dem Bernhard will ich natürlich nicht zu nahe treten, zumal er hier offensichtlich viel beiträgt.
Es gibt auch kein wie immer geartetes Problem in VBA. Es geht schlicht und ergreifend um Performance :-D

Die Unterschiede liegen beim konkreten Bereich bei Faktor 2 bis n.
Als fertige Funktion würde InOpArray in Frage kommen. Werde ich testen.

So viel ich aber verstehe müsste ich Richtung Inline Assembler gehen, oder eben fertige Funktionen verwenden, die Assembler verwenden.
Wichtig waren mir hier nur grundsätzliche Erfahrungswerte. Die aber offensichtlich zeigen, dass die Unterschiede in der Regel marginalst sind.
Das Beispiel ist ja nur exemplarisch und keinesfalls von Bedeutung.

Also, ich danke euch für eure Beiträge.
Meine zentrale Frage scheint beantwortet.

Übrigens kann ich aus VBA keine Wide-String Referenz übergeben, da VBA den UTF16 String zu Ansi konvertiert eine Referenz darauf übergeben würde.
Daher übergebe ich einen Pointer auf den String.
Die Übergabe als Ansi-String vermeide ich aber eher, da es dem Performance Gedanken zuwiderläuft. Werde es aber dennoch vergleichen.

LG Markus

Edit:

Zitat:

Die Funktionen macht eine Art StringReplace für WideString. Wenn der Ersetzungstext länger ist als 1 wird abgebrochen usw...

nicht wirklich, es wird im else Zeig behandelt, der nicht angeführt ist.

Zitat:

Man sieht nirgends das Anfordern des Speichers und die Freigabe

Da VBA einen BSTR benötigt, erzeuge ich diesen mit der angeführten Funktion SysReAllocStringLen. Diese fordert den Speicher an.
Die Freigabe erfolgt dann in VBA automatisch.

[p80286]

da ich ein wenig Erfahrung mit VBA habe, es ist wenig sinnvoll einfache VBA-Funktion durch in Delphi geschriebene zu ersetzen.Sinnvoll wird das erst, wenn größere Datenmengen verarbeitet werden bzw. wenn eine kompexere Funktionalität ersetzt werden soll.

Gruß
K-H