[gelöst] Warum sind die Klassen im Framework nicht partial?

Ja, ich wollte damit eher verdeutlichen, dass - immer meiner Meinung nach 😉 - solche Methoden, sobald sie etwas komplexer werden, nicht als statischen Methoden irgendeiner Hilfsklasse, wie Math es ist, taugen. Ist alles Speicher, der während der Ausführung permanent belegt ist.

Gruß,

LaTino

Ist alles Speicher, der während der Ausführung permanent belegt ist.

Auf was genau beziehst du diese Aussage?

Speicherverwaltung von Klassen mit statischen Methoden. Ist immer besser (soweit der gc das zulaesst) die Kontrolle über die Lebenszeit eines Objekts samt seiner Methoden zu haben. Meiner Meinung nach.

LaTino

Wäre schlimm 😉.

Ich rede von statischen Methoden. Wann wird der Speicher reserviert? Wann wird er freigegeben? Weisst du's? Ich hab' nur eine vage Vermutung.

LaTino

Nein, weiß ich nicht.

Nur würde ich mal behaupten, dass es keinen Unterschied macht, ob eine Methode statisch ist oder nicht, sobald ich mindestens eine Instanz erstellt habe.

(Ja ich weiß, dass es hier um Methoden geht, für die man nicht zwingend eine Instanz braucht 😉)

Nur würde ich mal behaupten, dass es keinen Unterschied macht, ob eine Methode statisch ist oder nicht, sobald ich mindestens eine Instanz erstellt habe.

Das ist auch der Fall, daher meine Verwunderung.

Glaub wir reden immer noch aneinander vorbei 😄.

Keine Diskussion, solang das Ding im Speicher liegt, dürfte sich das recht wenig nehmen. Um die Methode ausführen zu können, brauch ich nunmal Speicher, in den die Methode geschrieben wird. Logo. Nur halte ich es für eine feine Sache, wenn ich nach Benutzung der Methode aufräumen und den Speicher anderweitig benutzen kann. Bzw. wenn ich wenigstens weiß, wann ungefähr es soweit ist. Bei statischen Methoden hab ich ehrlich gesagt keinen Schimmer, ob und wann die wieder weggeräumt werden.

LaTino
EDIT: und wir reden ja von Klassen mit vielen komplexen Methoden. Würd ich nie im Leben statisch machen.

Wir müssen unterscheiden zwischen der MSIL-Repräsentation der Methode, und der kompilierten Variante.

Prinzipiell gilt:

Die MSIL-Variante wird bei statischen und Instanzmethoden in jedem Fall im Speicher gehalten, allein dadurch, dass die Assembly von der Platte gelesen wird. Hier nehmen sich beide nichts.

Beim ersten Zugriff (erste Ausführung) wird die jeweilige Methode kompiliert und der Maschinencode im Speicher abgelegt. Dieser wird gegebenenfalls wieder weggeworfen, wenn zB Speicher knapp wird. Da macht es auch keinen Unterschied, ob's eine statische oder eine Instanzmethode ist.

Instanzmethoden liegen nur einmal im Speicher, egal, wie viele Instanzen es gibt (aber erst, wenn sie aufgerufen wurden). Statische Methoden liegen ebenfalls nur einmal im Speicher, egal, ob und wie viele Instanzen es gibt (ebenfalls erst, wenn sie aufgerufen werden).

Fazit: Statische Methoden verbrauchen nicht mehr und nicht weniger Speicher als Instanzmethoden.

Ausnahme 😉: Virtuelle Instanzmethoden verbrauchen mehr Speicher als statische Methoden, da in jeder Ableitung der ursprünglichen Klasse ein Eintrag in der VTable notwendig ist. Aber selbst das sind nur ein paar Bytes.

All das zusammengenommen ergibt sich für mich im Moment (mag sein, dass ich noch was übersehen habe), dass es aus Performance- oder Speichergründen keinen Grund gibt, eine Instanzmethode einer statischen Methode vorzuziehen.

Die Dauer, die sie im Speicher bleibt. DAS ist mein Problem. Nicht die Menge an Speicher. Sondern die Kontrolle darüber, wann er reserviert wird, und wann er freigegeben wird.

LaTino

Okay, kapiert ^^

Ist IMHO aber kein Unterschied:

Die MSIL-Repräsentation bleibt in beiden Fällen über die gesamte Lebenszeit der AppDomain im Speicher, die kompilierte Version nach Bedarf.

Die Dauer, die sie im Speicher bleibt. DAS ist mein Problem.

Eigene AppDomain erstellen und nach der Ausführung der Funktion wieder entladen.

Allerdings sehe ich keinen Grund, warum der Zeiger auf eine Funktion freigegeben werden soll. Es müsste ständig von der Platte gelesen werden, der JIT-Compiler wäre am rödeln ohne Ende und Knappheit des Arbeitsspeicher sehe ich auch nicht als Problem

Knappheit des Arbeitsspeicher sehe ich auch nicht als Problem

Wenn man aus 'ner Ecke kommt, wo man in max. 2k Arbeitsspeicher programmieren musste, wird man der automatischen Speicherverwaltung von .NET und Konsorten immer etwas zweifelnd gegenüberstehen. Ist vielleicht nur 'ne Macke von mir.

LaTino

Hallo LaTino,

Ist vielleicht nur 'ne Macke von mir.

lach, ja, das ist es wohl. Und ich denke dabei sollten wir es belassen., Ich habe diese offtopic-Diskussion mal ausgegraut. Die Entscheidung, ob etwas statisch sein sollte oder nicht sollte man vom Modell abhängig machen, nicht von einer derart fragwürdigen Optimierung. Premature optimization is the root of all evil. 😃

herbivore