Delphi-PRAXiS - DLL Performance allgemein

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.

Delphi kann ganz gut andere Technologien konsumieren auf deren Layer Delphi aufbaut.
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:

Zitat von markus888 (Beitrag 1421847)

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.