"Component is TButton" oder "Component.ClassName"

[hoika]

Hallo,
ich möchte bei allen Buttons eines Forms eine Aktion durchführen, also etwa so

Delphi-Quellcode:

var
  iComponent: Integer;
  Component: TComponent;
  Button: TButton;  
begin
  for iComponent:= 0 to ComponentCount-1 do
  begin
    Component:= Components[iComponent);

     if Component is TButton then
     begin
       Button:= TButton(Component);
       //jetzt was mit dem Button machen
     end;

//     oder 
     if Component.ClassName='TButton' then
     begin
     end;
  end;

Gefühlt würde ich sagen, ClassName ist schneller, weil kein RTTI verwendet wird.

Was meint ihr?

[Klaus01]

Hallo,

solltest Du nicht besser classType verwenden anstelle von className?
Diskussion hier.

Grüße
Klaus

[hoika]

Hallo,
ClassType hört sich für mich auch wieder nach RTTI an.

[freimatz]

Hallo,
ich bin recht eindeutig für "Component is TButton".
Wenn Geschwindigkeit eine Rolle spielt dann hast Du ein falsches Design. In der UI spielt Geschwindigkeit eh meist keine Rolle.

[Uwe Raabe]

Zitat:

Zitat von hoika (Beitrag 1453171)

ClassType hört sich für mich auch wieder nach RTTI an.

Nicht wirklich:

Delphi-Quellcode:

function TObject.ClassType: TClass;
begin
  Pointer(Result) := PPointer(Self)^;
end;

[hoika]

Hallo,

Zitat:

Wenn Geschwindigkeit eine Rolle spielt

Einspruch, natürlich sollte die Performance immer eine Rolle spielen,
sonst hätten wir heute noch 286-er mit 16 MHz (ja der mit dem Turbo ! ;) )

[hoika]

Hallo Uwe,
das sieht auf jeden Fall schneller als mein String-Vergleich aus ;)

Danke.

[Stevie]

Bei

Delphi-Quellcode:

x is someclass

fügt der Compiler einen Aufruf auf System._IsClass ein. Das ist nicht nur >10mal schneller als der ganze Kram, der in TObject.ClassName und dem String vergleich passiert, sondern - und das ist viel wichtiger - es liefert auch True zurück, wenn x eine Instanz einer von someclass abgeleiteten Klasse ist (hallo Polymorphie)

Fast schockierend, dass Delphientwickler immer noch denken, dass etwas, was eine Funktion beinhaltet, die einen string zurückliefert, mit dem etwas gemacht wird, irgendwie schneller sein könnte als ein bisschen Pointer vergleichen. :stupid:

P.S.: Schneller als is wäre übrigens InheritsFrom wenn man auf den assigned Check verzichten kann - das spart nochmal einen Call ;)

[freimatz]

Zitat:

Zitat von hoika (Beitrag 1453178)

Hallo,

Zitat:

Wenn Geschwindigkeit eine Rolle spielt

Einspruch, natürlich sollte die Performance immer eine Rolle spielen,
sonst hätten wir heute noch 286-er mit 16 MHz (ja der mit dem Turbo ! ;) )

Einspruch abgelehnt. Natürlich sollte die Performance NICHT immer eine Rolle spielen, sondern nur in Ausnahmefällen.
https://clean-code-developer.de/die-..._Optimierungen

[Stevie]

Zitat:

Zitat von freimatz (Beitrag 1453185)

Einspruch abgelehnt. Natürlich sollte die Performance NICHT immer eine Rolle spielen, sondern nur in Ausnahmefällen.
https://clean-code-developer.de/die-..._Optimierungen

Auch falsch - es kommt auf den Code an, den man entwickelt. Wenn ich was in nem ButtonClick Implementiere ist es herzlich egal, obs in dem Bruchteil einer Nanosekunde oder in 5 Millisekunden passiert. Wenn man allerdings in einer Kern Laufzeit Klasse oder Methode entwickelt, dann ist es wichtig, die Sprache, Compiler und Standard Runtime zu kennen, damit man das Optimum rausholt.

Wenn man aber sieht, wie selbst manche Runtime Entwickler nen halbes Duzend Ebenen der Abstraktion aufeinander schichten und das Endergebnis einfach nur unerträglich langsam werden kann, dann könnte man einfach nur :kotz:


Übrigens regt sich fast jeder auf, dass dieses vermaledeite Electron so resourcenhungrig ist und nen blöder Chrome mit zig Tabs die Gigabytes auffuttert wie Kekse... aber Code Optimieren ist böse oder was? :D

[hoika]

Hallo,

Zitat:

und das ist viel wichtiger - es liefert auch True zurück, wenn x eine Instanz einer von someclass abgeleiteten Klasse ist

Gut zu wissen.

[freimatz]

@Stevie: Ich gebe Dir (fast) völlig recht.
"Auch falsch" - Nein, weil "es kommt auf den Code an, den man entwickelt." - Nichts anders sagte ich.
Hier ging es ja um TButton, also UI.

"halbes Duzend Ebenen der Abstraktion aufeinander schichten" - genau. Wenn schon da Design nichs taugt, dann nutzt eine Codeoptimierung hinsichtlich Performace (gar noch mit Assembler) auch nicht mehr viel. Gerade deswegen ist es wichtiger den Code schön zu haben, dann sieht man z.B. auch wo man Aufrufe gar nicht braucht oder man leicht ein Cache zwischenschieben kann.

Was meinst Du mit "Runtime Entwickler"? Ich selber habe ich auch schon Micros (8031/6502) oder damals für 640KByte programmiert. Da ist es was anderes. (Meine Aussagen beziehen sich auf Delphi.)

[Dennis07]

1. ist
   Delphi-Quellcode:

   Component:= Components[iComponent);

   syntaktisch falsch.
2. hilft dir
   Delphi-Quellcode:

   Component.ClassName = TButton.ClassName

   nicht weiter, weil es Groß/Kleinschreibung nicht Ignoriert. Stattdessen solltest du
   Delphi-Quellcode:

   ClassNameIs()

   verwenden.
3. ist der Vergleich von Strings immer eine der Aufwändigsten Operationen und sollte deshalb vermieden werden.
4. ist
   Delphi-Quellcode:

   ClassName

   für so etwas nicht gedacht. Dafür hat man ClassType.
5. verwendet
   Delphi-Quellcode:

   _isClass()

   überhaupt nicht die RTTI.

[Stevie]

Zitat:

Zitat von freimatz (Beitrag 1453188)

Was meinst Du mit "Runtime Entwickler"?

Ich meinte "Runtime Library Entwickler" - also die, die den Code schreiben, auf dem alles andere basiert und mit dem Geschwindigkeit der gesamten Anwendung steht und fällt.
Das sind sowohl Entwickler bei z.B. Embarcadero als auch Dritte und ggf Entwickler im eigenen Team/Unternehmen, die halt den Grundbau entwickeln und warten.

Außerdem heißt Performance für mich auch nicht nur "schnell genug" sondern ggf auch ressourcenschonend.

Aber langsam werden wir was das Thema hier angeht arg OT, evtl sollten wir das von nem Mod abtrennen und in ein neues Thema verfrachten lassen. :)

[hoika]

Hallo,
von mir aus kann hier zugemacht werden.
Ich habe meine Antwort ja bekommen.

Vielen Dank noch mal an alle.

[himitsu]

Ihr dürft hier auch nicht RTTI mit RTTI verwechseln.

Die "alte" RTTI aka TypeInfo ist sehr einfach und schnell.
Die neuere "erweiterte" RTTI ist da schon komplexer und langsamer, da hier mit instanziieren Objekten/Interfaces gearbeitet wird, welches ein klein bissl Zeit braucht, für die Initialisierung und auch beim Multithreading muß man teilweise etwas aufpassen.

Seit 2009 ist die TypeInfo von ANSI auf UTF-8 umgestellt. Wo vorher nur ein String verglichen wurde, muß er nun erst nach Unicode (UCS2 UTF-16) umgewandelt werden.
Also vom Aufbau her ist die TypeInfo seit Jahrzehnten praktisch unverändert und damals, auf den uralten langsamen Rechnern, bis hin zu Zeiten des DOS, war die auch schon sehr sparsam und flott. :zwinker:

PS: Neben ClassType/ClassInfo und ClassName gibt es auch InheritsFrom und ClassNameIs.
InheritsFrom wie IS und ClassNameIs halt mit String statt ClassType.

[Daniel]

Die Aussage, dass es eine alte und eine neue RTTI gebe, ist schlicht Unsinn.
Das, was Du in der Unit "System.RTTI.pas" findest, ist eine handliche Kapseln der RTTI, die intern nach wie vor wild auf Pointern herumhampelt. Wirf einfach einen Blick in besagte Unit.
Viel anders geht es ja auch kaum, da die Basis, auf der die RTTI arbeitet, ja ein und dieselbe ist.

[himitsu]

OK, dann trennen wir es sprachlich eben mehr an den APIs, als an der inneren Speicherung auf.

Direkte Casts/Offsets/Zugriffe in TObject, der Typ TypeInfo bzw. Unit TypInfo und die Unit RTTI.

In der TypeInfo, bzw. den bereitgestellten APIs, hast halt nicht auf alles Zugriff. (bzw. nicht so einfach/verständlich)
Da wurde ja doch schon so Einiges in den letzten Jahrzehnten nachgerüstet und zusätzlich noch die Möglichkeit alle Infos zu enumerieren.
Aber dafür ist der Zugriff mit der alten API auf einzelne Infos direkter/einfacher. (nicht erst über den großen Context und dessen Interfaces die Einiges konvertieren und netter bereitstellen)

Schon bei den Attributen finde ich die ganze Sache mit den instanziirten Objekten bissl overdressed. (sonst ist dort ja auch alles auf einfachen Typen/Records/Arrays aufgebaut)
So wie sie alle nutzen, hätte da ein

Delphi-Quellcode:

array[..] of record name: string; values: array of const; end

vollkommen gereicht.
Nunja, nun wird da mit instanziirten Objekten gearbeitet und man kann im Constructor wunderschöne Dinde veranstalten. :thumb:

[dummzeuch]

Es gibt übrigens auch noch ClassnameIs('Classname_goes_here'), nur falls die Auswahl noch nicht gross genug war. ;-)