DLL Performance allgemein

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

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]

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 von 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.

[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

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

[Delphi.Narium]

Da es darum geht, Delphi zu lernen, wäre mein Vorschlag:

Das vorhandene Access-VBA-Projekt vollständig auf Delphi umzustellen.

Der Zugriff auf Access-Datenbanken ist aus Delphi ja problemlos möglich.

Es entstünden dann zwei Projekte mit identischer Funktionalität, die dann in Bezug auf Schwierigkeit der Implementierung und auch auf Laufzeitverhalten verglichen werden könnten.

Prinipiell müssten ja sogar die API-Aufrufe aus VBA heraus auch in Delphi möglich sein.

Wenn dann dieser "Quasiklone" erstellt wurde, wäre der nächste Schritt, alle API-Aufrufe durch eigene (oder bereits in Delphi vorhandene) Implementierungen abzulösen.

Und wenn man dann was schnelleres gefunden hat, könnte man das in 'ner DLL kapseln, die dann auch aus VBA aufgerufen werden kann.

Auch wenn das jetzt irgendwie wie Kreisverkehr klingt: Zum Lernen ist das sicherlich nicht so ganz verkehrt.

Prinzipiell ist Delphi nicht langsamer als "irgendwas anderes".

In der Vergangenheit gab es immer wieder mal Tests und Vergleiche zwischen Delphi und "Anderem". Dabei kam zuweilen heraus, dass Delphi in Bezug auf Geschwindigkeit eher Platz 1 belegte.
Aber das kommt auch immer darauf an, auf was für einem System die Programme verglichen werden, mit welchen anderen Compilern verglichen wird ...

Meine Erfahrung ist jedenfalls: Delphiprogramme sind, wenn sie vernünftig implementiert wurden, sauschnell.

[MichaelT]

Lieben Gruß,

Ok. VB gibt den Speicher frei.

Du musst nicht in Richtung Inline Assembler gehen, aber zumindest die Sprache, den Compiler und dessen Ergebnisse sehr gut kennen. An sich brauchst du heute keinen Assembler mehr, außer eben wenn man eine Run-Time selbst baut. Du versuchst Teile der Run-Time Umgebung zu ersetzten, etwas plump formuliert.

In der MS Welt gilt an sich MS C(/C++) oder gcc. Mit allen Nachteilen wie fehlende Exceptions usw... Die C++ Welt verschärft sich wieder zusehends mit Myriaden von Schrauben, Switches usw... Optimierungen von denen man heute profitiert laufen mit Compiler in der nächsten Version mit der Revisionsnummer XYZ und sonst nicht.

Delphi ist nur dann echt langsam, wenn man selbst ein Bug hat eingebaut - das kann durchaus auch unbewusst passieren. Wenn man bei ein paar Milliarden Aufrufen zuviel und zu oft unnotwendigerweise konvertiert ...

Die MS hat sich in Häschenhäftigkeit damals so vorgestellt, dass die Leute in VB basteln und die Hardcode Typen in C ergänzen wofür die VB Programmierer keine Zeit haben oder wo wenige OS Spezialisten in der Sprache einfach runterklopfen was jene die sich OS Erweiterungen (auch im weiteren Sinne) bedienen brauchen.

--

Früher wurde eine DLL geschrieben, heute werden solche Erweiterungen gerne als komplette Runtime mit Implementierungssprache (Python, besser Javascript, Lua oder Go usw...) ausgeliefert. Seit gut 20 Jahren werden Maschinensteuerungen in Javascript geschrieben und waren immer sehr kompakt in der Verteilung bei selbst nicht sehr performanten Internetverbindungen.

---

Die Fälle in den das Auslagern von Delphi raus sich noch auszahlt sind ein paar Sonderfälle im techn. mathematischen Umfeld. Dabei handelt es sich um die üblichen Verdächtigen. Bei denen ist in der DLL schon Wissen gekapselt, das man selbst ohne Erfahrung auf dem Gebiet nicht so schnell aneignet.

Das Businessmodell 'Wir packen unser Wissen in eine DLL' usw... hat schon vor Jahren den Löffel abgegeben.

---

Java, .net und auch Smalltalk springen sehr schnell wenn es zur Sache geht auf harte Implementierungen je nach Technologie etwas anders genannt.

---

In Delphi verwirrt gerne dass für viele Befehle oder Funktion aus der Run-Time zwar sehr moderner und damit auch performanter Code wird generiert. Copy usw... wirkt alt, aber viel bestehender Code und hartnäckiger Widerstand über die Jahre haben dazu geführt, dass EMB nie die Chance hatte diese Befehle zu eliminieren.

---

Ansonsten machst du in dem Code nichts falsch. Du kannst dir den StringVuilder anschauen oder WideStringUtils. Die Implementierung dort ist ähnlich deinem Code.


Man lernt in Delphi wenn man mal die Performance profiled auch nicht aus ...

---

Wenn deine Frage darauf abzielte einen Applikationsunterbau der halt grad noch nicht ins Betriebssystem integriert ist dazuzubauen und auf dem dann verschiedene Technologien aufsetzen.

1. Delphi kann ganz gut andere Technologien konsumieren auf deren Layer Delphi aufbaut.
2. Integrieren ins Betriebssystem geht auch, aber dann kommt gerne auch ein 'geht' aber man muss wissen.

---

Auf einer etwas drüber liegenden Ebene ist Delphi eher 'UNIX' auf Windows.

Oder ein anders Beispiel. Du baust mit SAPx einen externen RFC Server. Ein externer RFC Server verhält wie ein SAP System und bietet ein paar spezifische Funktionen an. Den kann man als Anwendung laufen lassen, in einen Service verpacken usw ... ohne jetzt von einer spezifischen .net Version, einem Goodwill eines Großherstellers oder wem auch immer ausgeliefert zu sein. Die 'C' DLL ist da oder es gibt keine Alternative im oben erwähnten MS Intetgrationsmodell über den Weg.

---

Solange du homogen Delphi machst kannst du frisch von der Leber das Zeugs reinpacken wo du willst und OO funktioniert trotzdem. In dem Punkt kommt man schon weiter als mit VB.

---

Eine reine 'C'-DLL bietet nicht viel Nutzen und du hast kaum Komfort. Du fällst relativ schnell fast in pures C zurück. Sobald du Delphi Spezifika wegfallen lässt, dann ist es mit Luxus schnell vorbei. Das stört bei einer technischen Anbindung nicht unbedingt oder Low-Level Funktionen auf Basisdatentypen.

Zitat von markus888:

Danke erstmal für die Antworten.


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.

[Bernhard Geyer]

Zitat von MichaelT:

Der allgemeine Teil.

Tue mir den Bernhard nicht schimpfen.

Dein Ansinnen ist schon ok.

Das war doch kein Schimpfen. Markus hat doch gut erklärt was er eigentlich vor hat.
Da ist man gerne bereit weiter zu helfen/zu erklären.

Da gab schon ganz andere Antworten bei den weiter Hilfe praktisch gestorben war.