DLL Performance allgemein

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

[markus888]

Zitat von Delphi.Narium:

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

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

Genau das habe ich für ein Projekt vor.
Da ich allerdings erst seit kurzem mit Delphi arbeite, bin ich noch mit Basics beschäftigt. Außerdem habe ich auch noch anderes zu tun.

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