Werden statische Methoden immer im Speicher gehalten?

Question

Mein ganzes Entwicklerteam denkt, statische Methoden sind eine schreckliche Sache zu verwenden.

Ich sehe wirklich keine Nachteile in einigen Fällen. Als ich zuvor eine staatenlose Methode brauchte, verwendete ich zu diesem Zweck immer statische Methoden.

Ich stimme in einigen ihrer Punkte, z. Ich weiß, dass sie ziemlich schwer zu testen sind (obwohl es nicht unmöglich ist).

Was ich nicht bekomme ist, dass sie behaupten, statische Methoden sind immer im Speicher gehalten und füllen die grundlegende Speicherauslastung. Wenn Sie also 100 statische Methoden in Ihrem Programm verwenden, werden beim Starten des Programms alle Methoden in den Speicher geladen und füllen den Speicher unnötig auf. Weitere statische Methoden erhöhen das Risiko von Speichermangel.

Stimmt das?

Es ist ziemlich umständlich, eine neue Instanz einer Klasse erstellen zu müssen, nur um die Methode aufzurufen. Aber so machen sie es jetzt, erstellen Sie eine Instanz mitten in einer Methode und rufen Sie diese Methode auf, die nur eine statische Methode sein könnte.

Answer 1

Es gibt keinen Unterschied zwischen statischen und Instanzmethoden, soweit Speicher betroffen ist. Instanzmethoden haben nur ein zusätzliches Argument, this. Alles andere ist genau das gleiche. Auch die grundlegende Art und Weise, in der Erweiterungsmethoden leicht zu C# hinzugefügt werden konnten, war die Syntax, um dieses versteckte Argument freizulegen.

Methoden belegen Platz für ihren Maschinencode, den eigentlichen Code, den der Prozessor ausführt. Und eine Tabelle, die beschreibt, wie die Methode Objekte speichert, die dem Garbage Collector helfen, in lokalen Variablen und CPU-Registern enthaltene Objektstammwurzeln zu entdecken. Dieser Speicherplatz stammt aus dem "Loader-Heap", einer internen Datenstruktur, die von der CLR erstellt wird und mit der AppDomain verknüpft ist. Wird nur einmal ausgeführt, wenn die Methode gerade ausgeführt wird, Just-in-Time. Das Freigeben dieses Speicherplatzes erfordert das Entladen dieser App-Domäne. Statische Variablen werden ebenfalls im Loader-Heap zugewiesen.

Werfen Sie den großen Vorteil der statischen Methoden nicht weg. Sie können die Lesbarkeit und Wartbarkeit von Code erheblich verbessern. Dank ihres Vertrags können sie den Objektzustand nicht ändern. Sie können daher sehr wenige Nebenwirkungen haben, so dass es sehr einfach ist, darüber nachzudenken, was sie tun. Wenn sie jedoch statische Variablen hinzufügen, tun sie genau das Gegenteil, globale Variablen sind böse.

Answer 2

Es ist ziemlich umständlich, eine neue Instanz einer Klasse zu erstellen, nur um die Methode aufzurufen. Aber das ist, wie sie es jetzt tun

Sie sind lächerlich, um stumpf zu sein.

Wie commenter Groo auf die native kompilierte Ebene hingewiesen hat, unterscheidet sich eine Instanzmethode nicht einmal von einer statischen Methode. Es ist nur so, dass ein impliziter Parameter an die Instanzmethode übergeben wird, während bei der statischen Methode "Was Sie sehen, ist das, was Sie bekommen".

Die Laufzeit kann den Zugriff auf eine Methode optimieren. Es kompiliert die Methode möglicherweise nicht, bis sie das erste Mal ausgeführt wird. Es lädt möglicherweise nicht einmal die IL von Ihrer Baugruppe in den Speicher, bis die IL tatsächlich benötigt wird. Aber sie kann diese Optimierungen mit statischen und Instanzmethoden gleichermaßen durchführen.

In der Tat ist das Erzwingen aller Methoden zu Instanzmethoden schlechter als statische Methode verwenden, da es bedeutet, dass für einige Methoden willkürlich ein ansonsten nutzloses Objekt erstellt wird. Während die Laufzeit möglicherweise feststellen kann, dass die Objektreferenz unbenutzt ist und daher eine minimale Lebensdauer hat, kann sie nicht vermeiden, das Objekt vollständig zuzuweisen, selbst ein degeneriertes Objekt wird etwas Speicher belegen, während es lebt, und es wird hinzugefügt zu den Kosten der Müllabfuhr.

Und darüber hinaus nehmen wir an, dass Ihre Kollegen für einen Moment richtig waren. Was hättest du gewonnen? Irgendein messbarer Leistungsunterschied überhaupt? Zweifelhaft. Machen wir uns nichts vor: Managed Code und insbesondere C# haben das Potenzial, eine Reihe von leistungsreduzierenden Implementierungsdetails vor uns zu verbergen. Der Hauptgrund, warum wir eine verwaltete Code-Sprache wie C# verwenden, ist, dass wir so viel an Produktivität und Code-Korrektheit gewinnen, dass diese möglichen Ineffizienzen es wert sind. Die meiste Zeit und besonders auf modernen Computern sind sie praktisch unsichtbar.

Wie es passiert, Ihre Kollegen sind nicht richtig, und es ist in keiner Weise vorteilhaft, in Instanzmethoden, Methoden, die sonst statische Methoden sein könnten. Aber selbst wenn das nicht der Fall wäre, um Zeit damit zu verschwenden, verschleierten, unaussprechlichen Code zu schreiben, um einige ungemessene, nicht bewiesene Leistungskosten zu vermeiden, ist eine Verschwendung.(Und ich weiß, niemand hat sich die Mühe gemacht, den tatsächlichen Leistungsunterschied zu vergleichen, denn wenn sie hätten, hätten sie keine Verbesserung der Leistung gefunden, wenn sie alle statischen Methoden eliminiert hätten).