Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Delphi Geschwindigkeitsunterschiede bei Objekten/Pointern? (https://www.delphipraxis.net/12891-geschwindigkeitsunterschiede-bei-objekten-pointern.html)

Dark-Angel 13. Dez 2003 15:00

Re: Geschwindigkeitsunterschiede bei Objekten/Pointern?
 
@ Choose oder Hagen das Thema is ja sehr interessant gibt es Dazu noch Codebeispiele und weiterführene Literatur?

negaH 14. Dez 2003 14:47

Re: Geschwindigkeitsunterschiede bei Objekten/Pointern?
 
Choose hat das mit .NewInstance absolut richtig erklärt.

Zitat:

Das ist mir schon klar, Hagen, ich meinte aber eher Vorbelegung von Exemplarvariablen, Referenzzählern direkt in NewInstance anstatt diese Belegung in InitInstance bzw. im Konstruktor vorzunehmen. Hier könnten neue Nodes mithilfe eines "Node-Templates" mit rep movsd relativ performant erzeugt werden...?
Ich würde strikt zischen .NewInstance als Allokator und .InitInstance als Inizialisator Funktion trennen. Ein kopieren eines Templates könnte nötigenfalls auch in .InitInstance = Constructor durchgeführt werden. In den meisten Fällen wird aber eine Node selber wieder dynamische Felder besitzen, also zB. LongStrings, Dyn. Arrays usw. .InitInstance benutzt nun die RTTI der Klasse um gezielt und typgerecht diese Felder zu initiaisieren, übrigens ebefalls ein Overhead in der Performance. Würdest du nun die Fähigkeiten der Delphi Klassen kappen, eben mit Kopieren usw. dann wäre das höchstwahrscheinlich ineffizient. Denn 1.) reduzierst du so gewohnte High-Level Features die das Arbeiten erleichtern und 2.) implementierst du Präventiev-Code der verhindern soll das diese Features benutztbar sind. Dieser Code kostet nochmals Zeit.

Aus diesem Grunde habe ich zB. nicht eine Klasse nach unten beschnitten, sondern einen einfachen festen Record nach oben hin ausgebaut mit den Fähigkeiten die ich benötigte. Das sieht dann so aus das ein Record so konstruiert wurde das der Delphi Compiler "glaubt" er habe ein Interface vor sich. Angeblich sollen ja in Delphi 8 solche Record mit Record-Methoden ins Sprachkonzept aufgenommen wurden sein.

Hier im Forum findest du ein Beispiel dieser "forged" Interfaces. Der Name "forged Interface" ist eine Wortschöpfung von mir, also frage bitte nicht wo im WEB du mehr darüber erfahren kannst. Soviel ich weiß nirgendswo ausser hier, denn der benutzte Trick ist unbekannt.
Schau mal hier http://www.delphipraxis.net/internal...ght=waitcursor

Gruß Hagen

choose 15. Dez 2003 09:13

Re: Geschwindigkeitsunterschiede bei Objekten/Pointern?
 
Hallo Hagen,

das Konzept Deiner "forged interfaces" (FI) entsprichte dem der vielen "Garbage Collector for Delphi"-Artikeln. Eine Ähnliche Bibliothek zum Durchführen beliebiger Aktionen sowie einer Implementierung von "SmartPointern", die sogar auf nil zurückgesetzt werden habe ich vor ein paar Monaten geschrieben. Diese von mir als "implicit actions" getaufte Lösung beruht allerdings auf "echten Klassen", bei denen die durchzuführende Logik in einer Template-Methode, die im Konstruktor des abstrakten Vorfahren aller Aktionen aufgerufen wird, abgelegt.
Mit Sicherheit sind die FI ressourcensparender, jedoch für Entwickler, die ASM nicht verstehen, nur schwer nachzuvollziehen bzw zu erweitern.
Zu Deiner konkreten Lösung von WaitCursor möchte ich noch anmerken, dass Du von der Prämisse ausgehst, dass vor dem Aufruf von WaitCursor der StdCursor gesetzt ist, das ist nicht immer der Fall.

Für performante Lösungen halte ich Dein "Fälschungs-Konzept" der FI trotzdem für sehr interessant und auch die Erweiterbarkeit liese sich hinbekommen, sofern man eine zusätzliche Indirektion verwendet.
Danke für diese Inspiration!

negaH 15. Dez 2003 10:12

Re: Geschwindigkeitsunterschiede bei Objekten/Pointern?
 
Zitat:

Zu Deiner konkreten Lösung von WaitCursor möchte ich noch anmerken, dass Du von der Prämisse ausgehst, dass vor dem Aufruf von WaitCursor der StdCursor gesetzt ist, das ist nicht immer der Fall.
Das ist richtig. Ich gehe IMMER davon aus das Screen.Cursor in [crDefault,crHourGlass] sein darf, nichts anderes. Alle anderen Cursorarten sollten nur über TForm/TControl usw. eingestellt werden.

Zitat:

das Konzept Deiner "forged interfaces" (FI) entsprichte dem der vielen "Garbage Collector for Delphi"-Artikeln. Eine Ähnliche Bibliothek zum Durchführen beliebiger Aktionen sowie einer Implementierung von "SmartPointern", die sogar auf nil zurückgesetzt werden habe ich vor ein paar Monaten geschrieben. Diese von mir als "implicit actions" getaufte Lösung beruht allerdings auf "echten Klassen", bei denen die durchzuführende Logik in einer Template-Methode, die im...
Ja und Nein :) Die forged Interfaces können wie im WaitCursor gezeigt sogar vollständig statisch sein. Die Aufrufbedingungen der einzelnen VMT's ist ebenfalls anders als mit Delphi's Klasse + Interfaces. Die forged Interfaces sind am ehesten vergleichbar mit C++ Interfaces. In fakt sie sind in ihrer Speicherstruktur 1 zu 1 identisch zu C++ Interfaces. Allerdings, Vererbung oder Polymorphie sind damit nicht mehr so einfach möglich. Wie gesagt, sie sind für Speziallösungen ein guter Ansatz, aber ansonsten nur eine hypothetisch technologische Lösung.

Gruß Hagen


Alle Zeitangaben in WEZ +1. Es ist jetzt 09:59 Uhr.
Seite 2 von 2     12   

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