Es wäre um die beiden Methoden Aufrufe .Object langsammer. Auch über das gemeinsamme Identität-Interface muß man ja vorher mit .QueryInterface() -> ala "as" das Identitäts-Interface anfordern. Das sollte aber im Grunde vernachlässigenbar sein. Soll heisen: der minimale Performanceunterschied zu ungunsten meiner Lösung sollte dich nicht weiter stören da die Methode einfach sauberer und besser wartbar ist für die Zukunft. Im Grunde fallen ca. 16 zusätzliche Assemblerbefehle an.
Vorrausgesetzt man benutz .QueryInterface() statt den "as" Operator. Der "as" Operator macht wesentlich mehr als .QueryIntrface(). Bei deinem Problem wäre der "as" Operator eh die schlechteste Wahl das dieser eben auch eine
Exception auslösen wird wenn das Object das angeforderte Interface nicht enthält.
Du kannst aber in deinem Falle noch mehr an Performance rausholen. Deine Arrays[] auf die Interfaces sollten sortiert sein, und zwar binär nach .Object: TObject, so als wären es Cardinals. Wenn du nun in diesem Array[] nachschlagen willst ob ein Interface==Object schon vorhanden ist dann kannst du die Binäre Suche benutzen. Bei 1024 Einträgen im Array[] rufst du also maximal 12 mal die Methode .Object auf und weist danach a.) ob das Obhject/Interface schon im Array[] ist, und oder b.) an welcher Stelle im Array[] du es einfügen müsstest.
Somit wird die Frage wie schnell der Aufruf der Methode .Object: TObject ist, stark relativiert, weil du bessere Algorithmen benutzt.
Falls du aber diese Arrays[] sehr häufig aktualisieren musst, sprich es kommt sehr häufig vor das du neue Interface/Objecte dort einfügen und entfernen musst, dann sollte man dafür eine verlinkte Liste benutzen.
D.h. statt sich um 16 Taktzyklen mehr oder eniger Gedanken zu machen, solltest du die übergeordneten Algorithmen optimieren. Das bringt bei weitem mehr.
Beispiel, array mit 1024 Elementen, Aufrufe von .QueryInterface() 100 Taktzyklen, Aufruf von .Object +50 Taktzyklen
- binäre Suche -> 12 Aufrufe von .Object, macht 12 * 150 = 1800 Taktzyklen
- normale sequentiell Suche -> 513 Aufrufe von .Object durchschnitliche, macht 513 * 100 = 51300 Taktzyklen.
Wie man sieht selbst mit 50 Taktzyklen mehr bei der Benutzung von .Object + .QueryInterface ist das bei dem richtigen übergeordeneten und optimierten Algorithmus bei weitem effizienter als ein schlechter Algorithmus aber dafür nur .QueryInterface()
Fazit: halte den Code sauber und idiotensicher, optimiere besser andere Bereiche, wie zb. deine Ararys[], Listen etc.
Gruß Hagen