|
DLL Performance allgemein
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:
Hier eine Variante die direkt nach dem Vorkommen sucht:
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
Code:
API Deklarationen:
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
Code:
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).
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'; 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 |
AW: DLL Performance allgemein
Zitat:
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 |
AW: DLL Performance allgemein
Zitat:
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 |
AW: DLL Performance allgemein
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:
|
AW: DLL Performance allgemein
Zitat:
Eine 50 Zeilen Procedur kann schneller sein als irgendein angeblich simpler Einzeiler. |
AW: DLL Performance allgemein
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:
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.
p := Pos('a', s);
while p > 0 do begin s[p] := 'x'; p := Pos('a', s); end; |
AW: DLL Performance allgemein
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:
|
AW: DLL Performance allgemein
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:
|
AW: DLL Performance allgemein
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:
Zitat:
Die Freigabe erfolgt dann in VBA automatisch. |
AW: DLL Performance allgemein
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 |
AW: DLL Performance allgemein
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. |
AW: 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.
--- 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:
|
AW: DLL Performance allgemein
Zitat:
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. :-D |
AW: DLL Performance allgemein
Zitat:
Da ist man gerne bereit weiter zu helfen/zu erklären. Da gab schon ganz andere Antworten bei den weiter Hilfe praktisch gestorben war. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 17:53 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz