Properties - Vor- und Nachteile

GPC schrieb:

Und bevor du jetzt wieder mit "Aber du verwendest keine Properties" kommst, schau doch mal nach, wie die System.Array-Klasse die Eigenschaft "Length" definiert.. du wirst staunen, denn es ist ein Property!

Bisher staune ich noch über überhaupt nichts.

An GPC:

Eine Preisfrage für dich. Was geschieht in der folgenden Zeile?

cmp         dword ptr [ecx],ecx

Falls unbekannt, einfach Beitrag auf der letzten Seite von mir lesen.

Zeus

Btw eigentlich hab ich mich schon ausgeklinkt, aber über welche Zeitdimensionen reden wir?

14: 			object o = foo.MyFiled;
00000038 8B 45 F8             mov         eax,dword ptr [ebp-8] 
0000003b 39 40 04             cmp         dword ptr [eax+4],eax 
    15: 			o = foo.MyProperty;
0000003e 8B 4D F8             mov         ecx,dword ptr [ebp-8] 
00000041 39 09                cmp         dword ptr [ecx],ecx

genau der gleich Code (bis auf das unterschiedliche Register).

GPC schrieb:

Das Problem mit deinem Code liegt bei der Klasse "TestTime2" nicht daran, dass die Property getLength so lahm wäre (lol, ich muss darüber immer noch lachen), sondern dass der JIT-Compiler kein RCE durchführen kann, da du nicht per array.Length auf die Längenangabe zurückgreifst sondern die Längenangabe UNABHÄNGIG vom Array holst.

Es ist schon erstaunlich mit welcher Arroganz manche Personen im Netz unterwegs sind und wie sie versuchen andere Meinungen und Mitdiskutanten gezielt zu diskreditieren.

1. Das ist nicht "mein" Code, sondern eintriviales Beispiel.

2. Ich hatte bereits dem "Vollexperten" in dem besagten Forum erklärt das die RCE nicht allein verantwortlich für den Performanceeinbruch ist. Der Typ dort war sogar so dömlich, das er meine verlinkten Seiten mit den Aussagen von Jeffrey Richter verwechselte und mir dann auch noch unterestellte, ich würde das Prinzip der Datenkapselung nicht verstehen.

Am Ende begann er sogar meine Beiträge zu löschen, weil sie ihm nicht in das Weltbild passten.

Soviel zu Art. 5 GG.

Und jetzt erzählst du mir was diese Zeile kurz vor dem jb (Jump if Condition Is Met) macht?

cmp         eax,dword ptr [edx+4]

ich finds lustig dass du, StephanSch, in beiden Foren den Leuten Arroganz vorhälts und dabei gar nicht bemerkst dass die Diskussion in beiden Foren ähnlich verläuft. Vllt. liegst ja an dir?

Wenn du im anderen Forum deren Regeln zugestimmt hast, und in denen steht AFAIK dass deine Beiträge auch gelöscht werden können, dann brauchst du nicht mit dem GG argumentieren.
Außerdem finde ich es erstaunlich wie du hier den "Vollexperten" darstellst, immerhin hat er dir helfen probiert (kostenlos und in siener Freizeit). Lies mal selbst deine Beiträge (die übrigens auch zusammengefasster geschrieben werden können, da nicht für jeden Gedanken ein neuer Beitrag sein muss) und versetzt dich in die Lage der Leute die dir helfen wollen. Können diese nachvollziehen was du meinst, wenn du unsauber zitierst und Folgerunden hinschreibst die einen Zusammenhang vermuten lassen?

GPC

StephanSch schrieb:

An GPC:

Eine Preisfrage für dich. Was geschieht in der folgenden Zeile?
cmp         dword ptr [ecx],ecx
Falls unbekannt, einfach Beitrag auf der letzten Seite von mir lesen.

Kopier einfach mal meinen Code in eine Projektmappe, stell auf Release und schau dir die Ergebnisse an. Du solltest schon an den gleichen Zeiten (+- 1ms, je nach Lauf) feststellen, dass bei mir RCE funktioniert. Sorry, ich kann dir auch nicht weiter helfen. Wenn du's immer noch nicht verstehen willst, dann schlafe ich heute nacht auch ruhig wenn du alles auf öffentliche Felder umschreibst und Properties als Performancekiller bezeichnest.

StephanSch schrieb:

GPC schrieb:

Das Problem mit deinem Code liegt bei der Klasse "TestTime2" nicht daran, dass die Property getLength so lahm wäre (lol, ich muss darüber immer noch lachen), sondern dass der JIT-Compiler kein RCE durchführen kann, da du nicht per array.Length auf die Längenangabe zurückgreifst sondern die Längenangabe UNABHÄNGIG vom Array holst.

Es ist schon erstaunlich mit welcher Arroganz manche Personen im Netz unterwegs sind und wie sie versuchen andere Meinungen und Mitdiskutanten gezielt zu diskreditieren.

Stimmt. Stelle ich auch immer wieder fest.

1. Das ist nicht "mein" Code, sondern eintriviales Beispiel.

Du hast es gepostet und als Beispiel für den Performanceeinbruch durch Properties gebracht. Es ist dein Code. Ich habe den Code geändert und die Performance korrigiert.

2. Ich hatte bereits dem "Vollexperten" in dem besagten Forum erklärt das die RCE nicht allein verantwortlich für den Performanceeinbruch ist. Der Typ dort war sogar so dömlich, das er meine verlinkten Seiten mit den Aussagen von Jeffrey Richter verwechselte und mir dann auch noch unterestellte, ich würde das Prinzip der Datenkapselung nicht verstehen.

Ich kann nur über den von dir geposteten Code sprechen und bei dem war es einzig und allein RCE.

Am Ende begann er sogar meine Beiträge zu löschen, weil sie ihm nicht in das Weltbild passten.

Wird hier nicht passieren. Zukünftige Leser sollen von diesem Thread profitieren.

Und jetzt erzählst du mir was diese Zeile kurz vor dem jb (Jump if Condition Is Met) macht?
cmp         eax,dword ptr [edx+4]

Da du das aus dem Visual Studio Disassembler hast, kommt der Code doch von einem Debug-Build. Wie soll der bitte aussagekräftig sein, besonders da RCE nur im Release-Modus verfügbar ist?!

theta

Da du das aus dem Visual Studio Disassembler hast, kommt der Code doch von einem Debug-Build.

AFAIK geht das auch beim Release Build. Kann mich irren.

GPC schrieb:

Kopier einfach mal meinen Code in eine Projektmappe, stell auf Release und schau dir die Ergebnisse an. Du solltest schon an den gleichen Zeiten (+- 1ms, je nach Lauf) feststellen, dass bei mir RCE funktioniert.

Der Build ist ein Release-Build!

Und ich sage es noch einmal. Es macht für die CLR in der Laufzeitphase zur keinen Unterschied, ob du

for (int i = 0; i < time2.getLength; i++) {
    time2.Array[i] = i;
    i = (int)time2.Array[i];
}

oder

double[] array = time2.Array;
for (int i = 0; i < array.Length; i++) {
    array[i] = i;
    i = (int)array[i];
}

schreibst. Die RCE wird bei beiden Codesegmenten durchgeführt.

Es hängt davon ab, ob der JIT-Compiler den Property-Aufruf inlined. Alles andere ist völlig irrelevant!

Wenn du es nicht glauben willst, führe beide Codesegmente oben aus.

Zeus

Sealed die Klasse mal.

RCE wird in beiden Varianten NICHT durchgeführt.

GPC

theta schrieb:

Da du das aus dem Visual Studio Disassembler hast, kommt der Code doch von einem Debug-Build.

AFAIK geht das auch beim Release Build. Kann mich irren.

Stimmt, hast Recht.

@StephanSch
Ich klink mich jetzt aus, sollen andere die Diskussion weiterführen

Zeus schrieb:

Sealed die Klasse mal.

Hmm... die call-Befehle sind nun weg und die Laufzeiten sind auch gleich bei dem Beispielcode. Merkwürdig. Wieso werden die Aufrufe bei einer sealed Klasse geinlined, sonst aber nicht?

Zeus

StephanSch schrieb:

Zeus schrieb:

Sealed die Klasse mal.

Hmm... die call-Befehle sind nun weg und die Laufzeiten sind auch gleich bei dem Beispielcode. Merkwürdig. Wieso werden die Aufrufe bei einer sealed Klasse geinlined, sonst aber nicht?

Eine sealed Klasse ist nicht virtuell. IMO muss ich GPC widersprechen, dass virtuelle Funktionen geinlined werden kann, dass kann nicht einmal ein C++ Compiler.

anton_zeiler schrieb:

RCE wird in beiden Varianten NICHT durchgeführt.

Das ist korrekt. Zu erkennen an

cmp eax,dword ptr [edx+4]

Zeus schrieb:

Eine sealed Klasse ist nicht virtuell.

Mir scheinen die ganzen unteren Optimierungsphasen äußerst instabil zu sein, was ihre Vorhersehbarkeit anbelangt.

Aber das war bei .NET auch zu erwarten. Man ist der CLR ausgeliefert. Da hat man bei C++ doch etwas mehr Kontrolle über den tatsächlichen Output.

Shade Of Mine

Zeus schrieb:

Eine sealed Klasse ist nicht virtuell. IMO muss ich GPC widersprechen, dass virtuelle Funktionen geinlined werden kann, dass kann nicht einmal ein C++ Compiler.

Kommt auf den Fall an. Es ist durchaus möglich virtuelle Funktionen zu inlinen. Nicht in jeder Situation natürlich. Aber prinzipiell kann das ein C++ Compiler auch.

Die Frage ist ob das Objekt polymorph verwendet wird. Wenn ja, dann kann der Aufruf nicht geinlined werden (wir sind ja leider nicht in Eiffel) aber wenn es nicht polymorph verwendet wird dann ist es oft möglich zu inlinen.

Hier übrigens noch ein Blogeintrag zur RCE.

http://myexperiences-kuldeep.blogspot.com/2007/11/clr-performance-array-range-check.html

Man sieht, die MSDN ist nicht korrekt was die Aussagen zur RCE anbelangt.

Erst beim zweiten Codeversuch, fand offensichtlich eine RCE statt.

der MSDN-Artikel indem RCE vorkommt war damals genau wie er geschrieben wurde. Für die CLR 1.* und jetzt haben wir CLR 4

Außerdem: warum sollte die MSDN die Heuristiken festlegen, und das für immer, wenn sie bedacht sind das zu ändern und überall erwähnt wird dass man sich nicht darauf verlassen soll?

anton_zeiler schrieb:

der MSDN-Artikel indem RCE vorkommt war damals genau wie er geschrieben wurde. Für die CLR 1.* und jetzt haben wir CLR 4

Stimmt, hast Recht.

anton_zeiler schrieb:

Außerdem: warum sollte die MSDN die Heuristiken festlegen, und das für immer, wenn sie bedacht sind das zu ändern und überall erwähnt wird dass man sich nicht darauf verlassen soll?

Stimmt auch.

Ok, das Thema ist für mich damit erledigt. War ganz interessant. Danke an alle konstruktiv mitdiskutierenden Forenuser!