Properties - Vor- und Nachteile

[StephanSch]

Hallo!

Ich hatte kürzlich eine interessante Erfahrung in Bezug auf Properties (Eigenschaften) in C#. In einer rechenintensiven Anwendung hat der Compiler diverse Zugriffe nicht geinlined und die Performance brach weg.

Nach einiger Recherche zu dem Thema bin ich auf einige kritische Aspekte von Properties gestossen. Der bekannte Experte Jeffrey Richter schreibt dazu:

• A property may be read-only or write-only; field access is always readable and writable. If you define a property, it is best to offer both get and set accessor methods.
• A property method may throw an exception; field access never throws an exception.
• A property cannot be passed as an out or ref parameter to a method; a field can.
• A property method can take a long time to execute; field access always completes immediately. A common reason to use properties is to perform thread synchronization, which can stop the thread forever, and therefore, a property should not be used if thread synchronization is required. In that situation, a method is preferred. Also, if your class can be accessed remotely (for example, your class is derived from System.MashalByRefObject), calling the property method will be very slow, and therefore, a method is preferred to a property. In my opinion, classes derived from MarshalByRefObject should never use properties.
• If called multiple times in a row, a property method may return a different value each time; a field returns the same value each time. The System.DateTime class has a readonly Now property that returns the current date and time. Each time you query this property, it will return a different value. This is a mistake, and Microsoft wishes that they could fix the class by making Now a method instead of a property.
• A property method may cause observable side effects; field access never does. In other words, a user of a type should be able to set various properties defined by a type in any order he or she chooses without noticing any different behavior in the type.
• A property method may require additional memory or return a reference to something that is not actually part of the object's state, so modifying the returned object has no effect on the original object; querying a field always returns a reference to an object that is guaranteed to be part of the original object's state. Working with a property that returns a copy can be very confusing to developers, and this characteristic is frequently not documented.

Das sind durchaus kritische Aspekte. Auf MSDN sind Desigrichtlinien zur Properties zu finden. So heißt es dort:

Use a property when the member is a logical data member. In the following member declarations, Name is a property because it is a logical member of the class.

Dagegen sind die Ratschläge, wann Properties nicht eingesetzt werden sollten deutlich länger.

Use a method when:

• The operation is a conversion, such as Object.ToString.
• The operation is expensive enough that you want to communicate to the user that they should consider caching the result.
• Obtaining a property value using the get accessor would have an observable side effect.
• Calling the member twice in succession produces different results.
• The order of execution is important. Note that a type's properties should be able to be set and retrieved in any order.
• The member is static but returns a value that can be changed.
• The member returns an array. Properties that return arrays can be very misleading. Usually it is necessary to return a copy of the internal array so that the user cannot change internal state. This, coupled with the fact that a user can easily assume it is an indexed property, leads to inefficient code. In the following code example, each call to the Methods property creates a copy of the array. As a result, 2n+1 copies of the array will be created in the following loop.

http://msdn.microsoft.com/en-us/library/bzwdh01d(v=vs.71).aspx#cpconpropertyusageguidelinesanchor1

Jeffrey Richter kritisiert dabei das Properties viel zu oft von den Entwicklern verwendet werden ohne viel nachzudenken.

Java hat bekanntlich keine Properties, wie C#.

Wie seht ihr das? Wo und wann benutzt ihr Properties?

[Dravere]

Ich sehe die ganze Diskussion über die Properties als ziemlich schwachsinnig an. Es war von Anfang an für mich klar, dass Properties nur eine Kapselung von Getter und Setter sind. Früher waren ja noch nicht mal Auto-Properties möglich, da war der Unterschied noch deutlicher sichtbar.
Es ist mir absolut schleierhaft, was die Leute für ein Problem haben. Die einzige Kritik, welche man bringen könnte, ist, dass die gleiche Syntax für den Zugriff auf Properties wie auf Felder verwendet wird und daher Verwirrung stiften kann.

Auch die Kritik, dass Properties missbraucht werden, kann ich nicht verstehen. Ist mir bisher noch nicht vorgekommen, dass jemand eine Methode als Property implementiert hat.

Zu den Punkten von Jeffrey Richter:
1. readonly Properties ohne set accessor haben durchaus ihre Berechtigungen. Man schaue sich zum Beispiel Listen an, welche so zur Verfügung gestellt werden. Es soll nur ein Zugriff auf die Liste gegeben werden, aber nicht die Möglichkeit, die Liste zu ersetzen.
2. Er vergleicht alles zu Feldern. Felder macht man nicht öffentlich! Das widerspricht der Objektorientierung. Man müsste somit trotzdem Funktionen hinschreiben, ergo gelten alle Punkte genau gleich.
Es gibt ein paar Sonderfälle, wo man öffentliche Felder verwendet. Die sind aber meistens in sehr Performance kritischen Stellen vorzufinden. Diese Stellen verbirgt man aber, sofern dies möglich ist. Zudem führt man sie erst ein, wenn es erwiesen ist, dass dort Probleme auftauchen. Und nicht zuletzt: Ist vielleicht .Net die falsche Grundlage für Performance kritische Anwendungen?

Könntest du bitte die Quelle zu den Punkten von Jeffrey Richter angeben? Einfach so dahingestellt, wirken die völlig unsinnig.

Grüssli

[Rhombicosidodecahedron]

Ich muss dir da mit Java ein wenig widersprechen. Es hat zwar kein Eigenschaftskonstrukt an sich, aber in Java gibt es Konventionen, nach denen die Lese-Methode getProperty und Schreibe-Methoden setProperty heißen sollen. In C# Ist das auch Code sicht nicht viel anders. Da gibt es auch zwei Methoden, diese heißen bei der Eigenschaft Property get_Property und set_Property (Zumindest bei C#). Beweis folgender Code:

class YourArgumentIsInvalid
    {
        public String Property
        {
            get { return ""; }
        }

        public String get_Property() { return null; } 
    }

Summa sonstwas, das einzige was C# im Gegensatz zu Java zu Verfügung stellt, sind Metadaten, die angeben, dass bestimmte Methoden semantisch zusammen gehören. Es sind also alle Nachteile und Vorteile für Java get* und set* Methoden ebenso gültig.

Aber ich verwende immer Properties. Zur Validierung, Abhängigkeitsauflösung und auch in trivialen Fällen.

[GPC]

A property may be read-only or write-only; field access is always readable and writable. If you define a property, it is best to offer both get and set accessor methods.

Das ist natürlich quatsch. Wenn eine Eigenschaft zur lesend zur Verfügung gestellt werden soll, dann sollte man sich auch so definieren. Es gibt schließlich genug Klassen z.B. in C++, die nur ein getFoo(), aber kein setFoo() zur Verfügung stellen. Bei Properties ist es nicht anders. Manche Dinge soll man einfach nur lesen/nur schreiben können.

A property method may throw an exception; field access never throws an exception

Indirekt schon:

class Foo {
    public string str;
}

Foo f = new Foo();
int l = f.str.Length;  <-- NullReferenceException

Abgesehen davon: Exception-Handling muss man sowieso vernünftig implementieren.

A property method can take a long time to execute; field access always completes immediately.

Ja, weil sie Logik implementieren könnnen. Sehe ich kein Problem. Man muss ja keine 3000 Zeilen Property schreiben.

If called multiple times in a row, a property method may return a different value each time; a field returns the same value each time. The System.DateTime class has a readonly Now property that returns the current date and time. Each time you query this property, it will return a different value. This is a mistake, and Microsoft wishes that they could fix the class by making Now a method instead of a property.

Erstens kann sich auch ein Feld ändern.. wir leben in einer Multithreading-Welt. Und zweitens klingt der zweite Satz schon etwas merkwürdig. Es gibt genug Beispiele, in der Properties sich ändernde Werte zurückgeben.. und ich sehe da kein Problem.

Jeffrey Richter kritisiert dabei das Properties viel zu oft von den Entwicklern verwendet werden ohne viel nachzudenken.

Gut möglich. Auf der anderen Seite sind GetFoo() + SetFoo()-Methodenorgien auch keine tolle Sache.

Viele seiner Kritikpunkte beziehen sich im Allgemeinen darauf, dass ein Property auch noch Logik beinhalten kann. Na ja, that's not new to me, sir. Damit muss man rechnen und man muss es beim Programmieren berücksichtigen.

Wie seht ihr das? Wo und wann benutzt ihr Properties?

Grundsätzlich vermeide ich es, Felder public zu machen.. außer es ist nur so eine Mini-Struct die als Ersatz für ein Tuple mit 5 Werten oder so herhält. Mini-Datencontainer halt. Aber selbst da hat man Properties mit minmalem Mehraufwand implementiert und hat Vorteile für die Zukunft, falls man mal etwas Logik implementieren möchte.

Ansonsten gibt's bei mir nur Properties und Methoden in der öffentlichen Schnittstelle. Ich hatte deswegen auch noch keine Performanceeinbrüche. Und hey: Properties kann man für Databinding verwenden.. Felder nicht. Properties kann man virtual machen und dann überschreiben.. Felder nicht. Felder sind immer r/w.. Properties kann man feiner einstellen.
Der Einsatzzweck von Methoden und Properties überschneidet sich teilweise.. ich halte es persönlich so, dass ich kleinere Berechnungen/Aufgaben auch mal in einer Property mache.. wenn's was größeres ist, dann landet es in einer Methode.

[StephanSch]

Dravere schrieb:

Die einzige Kritik, welche man bringen könnte, ist, dass die gleiche Syntax für den Zugriff auf Properties wie auf Felder verwendet wird und daher Verwirrung stiften kann.

Die MSDN rät zumindest bei Arrays strikt von der Nutzung von Properties ab und das zur Recht!

Wenn man bedenkt das im Code kaum ein Unterschied zu einem gewöhnlichen Arrayzugriff zu sehen ist, ist das mehr als nur verwirrend.

Das mag bei einer 0815 Applikation nicht der Fall sein, aber bei komplexen umfangreichen Code durchaus.

Dravere schrieb:

Auch die Kritik, dass Properties missbraucht werden, kann ich nicht verstehen. Ist mir bisher noch nicht vorgekommen, dass jemand eine Methode als Property implementiert hat.

Ich habe schon etliche Properties gesehen, die dutzende Zeilen Code enthielten.

Dravere schrieb:

Und nicht zuletzt: Ist vielleicht .Net die falsche Grundlage für Performance kritische Anwendungen?

Das .NET per se nicht geeignet ist für zeitkritische Anforderungen ist ein Mythos, genau wie bei Java.

Man kann durchaus von einer .NET Applikation erwarten das sie auch die erforderliche Performance bringt.

[StephanSch]

GPC schrieb:

Ja, weil sie Logik implementieren könnnen. Sehe ich kein Problem. Man muss ja keine 3000 Zeilen Property schreiben.

Dazu schreibt die MSDN:

"Use a method when the operation is expensive enough that you want to communicate to the user that they should consider caching the result."

GPC schrieb:

Erstens kann sich auch ein Feld ändern.. wir leben in einer Multithreading-Welt. Und zweitens klingt der zweite Satz schon etwas merkwürdig. Es gibt genug Beispiele, in der Properties sich ändernde Werte zurückgeben.. und ich sehe da kein Problem.

Die MSDN sieht da aber offensichtlich schon ein Problem. Auch dort heißt es zu dem Thema.

"Use a method when calling the member twice in succession produces different results."

GPC schrieb:

Gut möglich. Auf der anderen Seite sind GetFoo() + SetFoo()-Methodenorgien auch keine tolle Sache.

Es geht ja nicht darum auf Properties zu verzichten, sondern sie wohlüberlegt einzusetzen.

GPC schrieb:

Ansonsten gibt's bei mir nur Properties und Methoden in der öffentlichen Schnittstelle. Ich hatte deswegen auch noch keine Performanceeinbrüche.

Ich wie gesagt schon und das sogar gravierend.

Ich werde mich in Zukunft wohl exakt an die Vorgabe halten:

"Use a property when the member is a logical data member."

Properties sind eine feine Sache, aber bei ihrem Einsatz kann man auch mal schnell den Überblick verlieren und alles mögliche "reinstopfen" und "raushauen".

[anton_zeiler]

@StephanSch: wenn dir OO und Eigenschaften nicht liegen und Performance sehr wichtig dann nimm doch Assembler, da hast du keine Felder mehr sondern nur noch Register und Adressen. Performanter und ungekapselter gehts nicht mehr.

[StephanSch]

anton_zeiler schrieb:

@StephanSch: wenn dir OO und Eigenschaften nicht liegen und Performance sehr wichtig dann nimm doch Assembler, da hast du keine Felder mehr sondern nur noch Register und Adressen. Performanter und ungekapselter gehts nicht mehr.

Was ist denn das für eine dämliche Antwort?

OO hat nichts mit Properties zu tun.

Und das ich etwas gegen OO hätte, ist auch nirgendwo zu lesen, sondern eine absurde Unterstellung.

[anton_zeiler]

OO hat mit Objekten zu tun, klar. Und ein Objekt besteht aus Zustand, Verhalten und Identität. Der Zustand wird durch Felder repräsentiert, die jedoch aufgrund von Kapselung nicht öffentlich gemacht werden sollen. Ergo wird der (öffentliche zugreifbare) Zustand per Properties dargestellt. Somit haben Properties in C# wohl etwas mit OO zu tun.

Für alles andere sind Properties auch nicht gedacht. Wo ist also dein Problem?
Alleine schon aus der Unterscheidung Zustand oder Verhalten ergibt sich der semantische Unterschied zwischen Property und Method.

Felder sollte nie öffentlich gemacht. Und falls du doch meinst dann schau dir Assembler an.

[theta]

anton_zeiler = Troll bitte nicht füttern.

[anton_zeiler]

@theta: danke, aber bitte passt nicht? Dass das mit dem Assembler sarkastisch ist weiß ich selbst. Der Rest ist meine Meinung zu OO und wenn es hier nicht gewollt ist, dass ich diese teile auch gut. Zumal ich finde dass diese Meinung gar nicht falsch ist.
Super Forum, war zwar nur kurz hier, aber was solls...

[GPC]

StephanSch schrieb:

GPC schrieb:

Ja, weil sie Logik implementieren könnnen. Sehe ich kein Problem. Man muss ja keine 3000 Zeilen Property schreiben.

Dazu schreibt die MSDN:
"Use a method when the operation is expensive enough that you want to communicate to the user that they should consider caching the result."

Genau so halte ich es auch.

GPC schrieb:

Erstens kann sich auch ein Feld ändern.. wir leben in einer Multithreading-Welt. Und zweitens klingt der zweite Satz schon etwas merkwürdig. Es gibt genug Beispiele, in der Properties sich ändernde Werte zurückgeben.. und ich sehe da kein Problem.

Die MSDN sieht da aber offensichtlich schon ein Problem. Auch dort heißt es zu dem Thema.
"Use a method when calling the member twice in succession produces different results."

Da ist die MSDN nicht den HTML-Code wert, mit dem sie erstellt wurde Es gibt so zig viele Properties, die Werte zurückliefern, die sich ändern können. Nicht nur in den Windows Forms, auch in zig Bibliotheken. Mag sein dass das von den MS-Leuten mal als Designidee gedacht war.. aber durchgesetzt hat es sich nicht. Und ich sehe auch nicht warum es problematisch sein sollte.

GPC schrieb:

Ansonsten gibt's bei mir nur Properties und Methoden in der öffentlichen Schnittstelle. Ich hatte deswegen auch noch keine Performanceeinbrüche.

Ich wie gesagt schon und das sogar gravierend.

Und das kam GANZ SICHER von Properties? Ich verwende sie praktisch ausschließlich und meine Programme haben nie Probleme. Die IL-Anweisungen beim Zugriff auf eine Property sind auch.. na ja.. übersichtlich ^^ Es ist mehr als bei einem Feld, klar, weil es im Endeffekt ein virtual call sein kann. Aber das darf die Performance nicht ins unerträgliche reißen.

Ich werde mich in Zukunft wohl exakt an die Vorgabe halten:
"Use a property when the member is a logical data member."

Die Vorgabe: "Keine Felder in der Schnittstelle" sollte mehr gelten Ansonsten würd ich deinen Code nicht unbedingt pflegen wollen.

Properties sind eine feine Sache, aber bei ihrem Einsatz kann man auch mal schnell den Überblick verlieren und alles mögliche "reinstopfen" und "raushauen".

Na ja, so knifflig sind sie jetzt auch nicht. Es gibt sicher schwierigere Entscheidungen als Properties oder nicht

[Zwergli]

GPC schrieb:

GPC schrieb:

Ansonsten gibt's bei mir nur Properties und Methoden in der öffentlichen Schnittstelle. Ich hatte deswegen auch noch keine Performanceeinbrüche.

Ich wie gesagt schon und das sogar gravierend.

Und das kam GANZ SICHER von Properties? Ich verwende sie praktisch ausschließlich und meine Programme haben nie Probleme. Die IL-Anweisungen beim Zugriff auf eine Property sind auch.. na ja.. übersichtlich ^^ Es ist mehr als bei einem Feld, klar, weil es im Endeffekt ein virtual call sein kann. Aber das darf die Performance nicht ins unerträgliche reißen.

Sein Problem ist die Range Check Elimination, die bei seinem Code mit Properties nicht greift. Siehe dazu die Diskussion auf mycsharp.de. Nur scheint er das nicht wahrhaben zu wollen und verteufelt Properties jetzt im allgemeinen...

[GPC]

Zwergli schrieb:

Sein Problem ist die Range Check Elimination, die bei seinem Code mit Properties nicht greift. Siehe dazu die Diskussion auf mycsharp.de. Nur scheint er das nicht wahrhaben zu wollen und verteufelt Properties jetzt im allgemeinen...

Danke für den Link

Fail druid, I salute to you.

[Dravere]

StephanSch schrieb:

Dravere schrieb:

Die einzige Kritik, welche man bringen könnte, ist, dass die gleiche Syntax für den Zugriff auf Properties wie auf Felder verwendet wird und daher Verwirrung stiften kann.

Die MSDN rät zumindest bei Arrays strikt von der Nutzung von Properties ab und das zur Recht!

Wenn man bedenkt das im Code kaum ein Unterschied zu einem gewöhnlichen Arrayzugriff zu sehen ist, ist das mehr als nur verwirrend.

Das mag bei einer 0815 Applikation nicht der Fall sein, aber bei komplexen umfangreichen Code durchaus.

Das wäre auch bei einer 0815 Applikation, was auch immer du darunter verstehst, verwirrend. Code liest sich genau gleich, egal was für eine Applikation man programmiert ... lol

Die MSDN rät aber nicht deswegen davon ab, wenn du die MSDN mal korrekt liest. Problem ist, dass man von aussen Zugriff auf die Innereien des Objektes bekommt. Das widerspricht dem Ansatz von OO.

Zudem ist mir ein Rätsel, was genau du hier als verwirrend siehst. Nur weil man ein Indexer auf ein Objekt anwenden kann, ist dies doch nicht verwirrend?

StephanSch schrieb:

Ich habe schon etliche Properties gesehen, die dutzende Zeilen Code enthielten.

Nur weil es ein paar Zeilen Code enthält, muss dies noch nicht schlimm sein. Zum Beispiel können ein paar Validierungen durchgeführt werden. Oder wenn ein IEnumerable zurückgegeben wird, kann auch eine Linq-Expression dort stehen. Sowas sehe ich durchaus als legitim an in einem Property.

Zudem wer duzende Zeilen Code in einer Methode hat, hat sowieso meistens ein Design-Problem.
Und schlussendlich: Nur weil ein Feature missbraucht werden kann, heisst dies sowieso nicht, dass man es nicht einführen soll. Sonst dürfte man gar keine Programmiersprache entwickeln

StephanSch schrieb:

Dravere schrieb:

Und nicht zuletzt: Ist vielleicht .Net die falsche Grundlage für Performance kritische Anwendungen?

Das .NET per se nicht geeignet ist für zeitkritische Anforderungen ist ein Mythos, genau wie bei Java.

Man kann durchaus von einer .NET Applikation erwarten das sie auch die erforderliche Performance bringt.

Dies als Mythos zu bezeichnen, kommt meistens von den Java Leuten oder Leuten, welche nicht verstanden haben, was andere genau sagen wollten. Du kannst gar keine zeitkritischen Anforderungen mit Java oder C# realisieren, weil dir jederzeit der GC, JIT oder sonst was einen Strich durch die Rechnung machen können. Du hast einfach zu wenig Kontrolle über die Rahmenbedingunen der Ausführung. Zudem kann ein Kompiler nachwievor viel aggressiver optimieren bei C oder C++ Code.

Ein Mythos dagegen ist, dass man keine performante Anwendungen in C# oder Java realisieren kann. Man kann auch C# oder Java Code so optimieren, dass auch grössere Aufgaben meistens in vernünftiger Zeit erledigt werden. Wenn es aber eben darum geht, das letzte Bisschen zu optimieren, also zeitkritische Applikationen zu entwickeln, dann hat man mit C# oder Java keine Chance gegen C oder C++.

Zwergli schrieb:

Sein Problem ist die Range Check Elimination, die bei seinem Code mit Properties nicht greift. Siehe dazu die Diskussion auf mycsharp.de. Nur scheint er das nicht wahrhaben zu wollen und verteufelt Properties jetzt im allgemeinen...

...
Dann soll er halt auf Properties verzichten. Wird ihn halt nur jeder auslachen bei der Argumentation

Grüssli

[StephanSch]

anton_zeiler schrieb:

OO hat mit Objekten zu tun, klar.

Das hast du verblüffend schnell erkannt.

anton_zeiler schrieb:

Somit haben Properties in C# wohl etwas mit OO zu tun.

Das ist falsch! Properties sind ein Werkzeug zur Realisierung der OOP, sie sind aber nicht notwendig, um eine OO-Sprache zu realisieren. Sie sind ein weiteres Sprachkonstrukt, genau wie die foreach-Schleife.

Willst du mir nun weismachen, man bräuchte foreach Kontrollstrukturen um Programme schreiben zu können?

anton_zeiler schrieb:

Felder sollte nie öffentlich gemacht. Und falls du doch meinst dann schau dir Assembler an.

Deine Aussagen sind ziemlich irrelevant, weil hier niemand behauptet hat, man solle Felder öffentlich zugänglich machen.

[StephanSch]

Dravere schrieb:

Dies als Mythos zu bezeichnen, kommt meistens von den Java Leuten oder Leuten, welche nicht verstanden haben, was andere genau sagen wollten. Du kannst gar keine zeitkritischen Anforderungen mit Java oder C# realisieren, weil dir jederzeit der GC, JIT oder sonst was einen Strich durch die Rechnung machen können. Du hast einfach zu wenig Kontrolle über die Rahmenbedingunen der Ausführung. Zudem kann ein Kompiler nachwievor viel aggressiver optimieren bei C oder C++ Code.

Darum geht es überhaupt nicht. Niemand hat ausgesagt, dass eine interpretierte Sprache keinen Overhead mit sich bringt und plattformspezifische Otimierungen, z.B. durch Inline-Assembler und prozessorabhängige Opcodes mit C# zu realisieren sind.

Es ging um die Aussage, ob Java oder .NET überhaupt die notwendige Performance leisten können oder prinzipiell ungeeignet sind für jegliche Performance-Anwendungen.

Und pauschal zu sagen, nimm kein .NET, wenn du Performance willst, ist nunmal völliger Unsinn. Es hängt ganz davon ab, was überhaupt realisiert werden soll und wie konkret die Anforderungen aussehen.

In Echtzeitsystemen habe ich auch konkrete Anforderungen an die Rechtzeitigkeit, die mir ein Standard-Betriebssystem nicht gewährleisten kann. Da nutzt mir C/C++ auch nicht weiter, weil ich ohne Treiber auch den Kernel mit dem Scheduler und Filesystem dazwischen geschaltet habe.

Dravere schrieb:

Ein Mythos dagegen ist, dass man keine performante Anwendungen in C# oder Java realisieren kann. Man kann auch C# oder Java Code so optimieren, dass auch grössere Aufgaben meistens in vernünftiger Zeit erledigt werden.

So ist es!

Dravere schrieb:

Wenn es aber eben darum geht, das letzte Bisschen zu optimieren, also zeitkritische Applikationen zu entwickeln, dann hat man mit C# oder Java keine Chance gegen C oder C++.

Das ist zweifelsohne korrekt.

Dravere schrieb:

Dann soll er halt auf Properties verzichten. Wird ihn halt nur jeder auslachen bei der Argumentation

Welche Argumentation? Und wer hat gesagt, ich wolle auf Properties verzichten?

[StephanSch]

GPC schrieb:

Die Vorgabe: "Keine Felder in der Schnittstelle" sollte mehr gelten

In C# kann eine Schnittstelle ohnehin keine Felder enthalten.

[dravere_mobile]

StephanSch schrieb:

Es ging um die Aussage, ob Java oder .NET überhaupt die notwendige Performance leisten können oder prinzipiell ungeeignet sind für jegliche Performance-Anwendungen.

Und pauschal zu sagen, nimm kein .NET, wenn du Performance willst, ist nunmal völliger Unsinn. Es hängt ganz davon ab, was überhaupt realisiert werden soll und wie konkret die Anforderungen aussehen.

Das habe ich aber so nie gesagt. Ich habe nur die Frage in den Raum gestellt, ob vielleicht .Net für Performance kritische Anwendungen die falsche Wahl ist. Diese Frage sollte man sich durchaus stellen. Ich habe nie irgendetwas in der Richtung behauptet, dass .net prinzipiell ungeeignet sei für jegliche Performance-Anwendungen.

StephanSch schrieb:

Welche Argumentation? Und wer hat gesagt, ich wolle auf Properties verzichten?

Naja, wenn du alle diese Nachteile bei den Properties siehst und dann noch daran glaubst, dass sie für diesen Performance-Einbruch verantworlich sind, wirst du in der Zukunft sicherlich des Oefteren aus Properties verzichten. Nur solltest du dabei nie auf die Argumentation im mycsharp Forum verweisen oder eine ähnliche bringen

Grüssli

[StephanSch]

dravere_mobile schrieb:

Naja, wenn du alle diese Nachteile bei den Properties siehst und dann noch daran glaubst, dass sie für diesen Performance-Einbruch verantworlich sind, wirst du in der Zukunft sicherlich des Oefteren aus Properties verzichten.

Ich betrachte überall Vor- und Nachteile und höre mir auch Kritiken an. Die genannten Nachteile stammen immerhin von einer Person, die auf dem amerikanischen Markt einen Bestseller zur CLR geschrieben hat.

Diese Person rät genausowenig, wie ich von Properties ab, sondern geht detailliert auf diese ein.

Zum Thema Performance. Natürlich sind die Properties kritisch für die Performance, wenn sie nicht geinlined werden. Es sind immer noch Methoden.

Wenn ich ILDASM zu Rate ziehe, sehe ich sofort das der Compiler selbst im Release-Build unter aktivierter Optimierung einen callvirt IL-Befehl vom Typ instance float64[] ::getArray() ausführt.

callvirt wird vom JIT-Compiler derart übersetzt das die CLR auch eine NullReferenceException auslösen kann. Die Überprüfung auf null wird auch bei nicht virtuellen Instanzmethoden durchgeführt und ist langsamer als ein normaler call.