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