Zugriff auf Eigenschaften vs. Eigenschaften in Variable halten

[TomLudwig]

Hallo zusammen,

man kann auf den Pfad zu einer Datenbank (z.B.) wie folgt zugreifen:

Code

Dim session as New NotesSession
Dim database as NotesDatabase
Dim filepath as String

Set database = session.CurrentDatabase
Set filepath = database.FilePath

oder

Code

Dim session as New NotesSession
session.CurrentDatabase.FilePath

Für mich stellt sich nun die Frage, wann man lieber eine eigene Variable für eine Eigenschaft (z.B. Pfad zur Datenbank) deklariert oder immer auf die Eigenschaft selbst zugreift.

Im Zuge der Lesbarkeit des Codes würde ich die erste Variante vorziehen, wenn z.B. "filepath" an drei weiteren Stellen im Code verwendet wird.
Im Zuge der Performance / der Speichernutzung bin ich mir nicht sicher ...

Wie programmiert ihr? Wo kann ich was über mein "Problem" nachlesen?

Viele Grüße!

[ZaLudtske]

Hallo,

ich programmiere in der Variante 1  (die Geschwätzige) .  Ich gebe der Lesbarkeit nach den Vorrang einer wahrscheinlich nicht spürbaren Perfomance-Steigerung.


Rainer

[klaussal]

Aus diesem Grund:

wenn z.B. "filepath" an drei weiteren Stellen im Code verwendet wird.

[ata]

... Werte in Variablen sind besser für die Performance, denn jeder weitere Zugriff durch die Objektinstanzen kostet Performance

Ich verwende beides - je nachdem, was wie oft verwendet wird. Bei mehr als einmaligem Gebrauch werden Variablen angelegt...

Toni

[TomLudwig]

Stimmt, die Property Statements müssen ja durchlaufen werden... DANKE!

[koehlerbv]

Ich bin der Meinung, dass man das nicht pauschal beantworten kann.
Einerseits stehen etliche Objekte nach der ersten Instantiierung (die ja sowieso notwendig ist) sowieso im Speicher zu Verfügung. Insofern ist die Performancefrage von beispielsweise

Code

Dim session As New NotesSession
dim dbCurrent as NotesDatabase
Dim szServerName as String
Set dbCurrent = session.CurrentDatabase
szServerName = dbCurrent.Server
Messagebox szServername

versus

Code

Dim session As New NotesSession
Messagebox session.CurrentDatabase.Server

eher eine Randbemerkung.
Für mich steht da eher die Frage der
- doppelten Deklaration (in QuerySave - nachdem Source eh instantiiert ist - noch das Backend-Dokument erneut zu instantiieren, halte ich für doppelt gemoppelt)
- der Lesbarkeit (und das ist manchmal - vor allem bei umfangreicheren Code! - essentiell). Und da muss es wohl jeder nach seinem Gusto halten. Bleiben wir beim Beispiel QuerySave: Ein Source.Document ist für mich sprechender als ein Set docCurrent = Source.Document und anschliessender Gebrauch als docCurrent. Aber *das* muss m.E. jeder selbst entscheiden bzw. muss man im Team gemeinsam festlegen.

Eine Gefahr sehe ich (und habe sie auch kennengelernt), wenn man mit der Übernahme von Properties in Variable arbeitet: Es geht (im Gegensatz zum direkten Zugriff auf das Objekt und seine properties) viel schneller, dass man zwischendurch der Variablen "aus Versehen" einen neuen, ganz anderen Wert zuweist, da man den Bezug verloren / übersehen hat. Mit dem Objekt an sich (nochmals: Das steht sowieso im Speicher!) geht das nicht ganz so einfach.

Aber nochmals: Jeder nach seinem Gusto, solange "Sauberkeit und Ordnung im Schlachthof" herrscht.

Bernhard

[flaite]

Seh das auch so wie Bernhard,

Performance-Mutmassungen sind eine gefährliche Geschichte.
Lesbarkeit ist ein sehr wichtiges Kriterien.

Ob man eine eigene lokale Variable auf den Stack haut oder über eine Objektreferenz zugreift, die sich auch auf dem Stack befindet, wird sich unterhalb des Milisekunden-Bereichs abspielen.
Ist also nicht merkbar.

Gruß Axel