Einige mehr Leistung und Optimierung Fragen ... (Local vs. Klassenvariablen & iterative vs. rekursiven Baum Einfügen/Suchoperationen)

Question

Gute Nacht,

Ich habe zwei kleine Fragen, die dumm erscheinen, aber die sehr wichtig für einige Implementierungsentscheidungen muss ich jetzt machen ...

1) Kann es in Bezug auf die Leistung rentabel sein, "Arbeitsvariablen" von Funktionen zu deklarieren, die mehrere hundert Mal als (private) Klassenvariablen bezeichnet werden, anstatt sie zu instanziieren jeder Anruf (um mehrere unnötige Zuweisungen und folglich Speicherdruck und mehr GC-Ausführungen zu vermeiden)? Macht es einen Unterschied in Bezug auf die Leistung?

2) Gibt es signifikante Leistungszuwächse durch Codieren von Tree-Insertion/Lookup mit iterativen Funktionen anstelle von rekursiven Funktionen? In diesem speziellen Fall kann eine Suche bis zu 160000 rekursive Aufrufe aufnehmen, so viele wie die Knoten der Baumstruktur (wie auch die Einfügungen), also dachte ich darüber nach, diese Funktionen als iterative anstelle von rekursiven zu implementieren.

Vielen Dank.

Answer 1

1) Es kann rentabel sein, Ihre Arbeitsobjekte als private Klassenvariablen zu deklarieren, aber nicht so oft, wie Sie vielleicht denken. Es gibt mehrere Dinge, die Sie beachten müssen.

Erstens macht die Verwendung von privaten Klassenvariablen Ihre Klasse inhärent nicht Thread-sicher. Es sei denn, Sie verwenden lokalen Threadspeicher, der mit eigenen Leistungsproblemen einhergeht.

Es stellt sich oft heraus, dass die Wiederverwendung eines Objekts teurer ist als die Zuweisung eines neuen Objekts. Zum Beispiel ist das Löschen eines Hashsets oder einer Liste oft sehr viel teurer als das Zuweisen eines neuen und das Abholen durch den Garbage Collector, wenn Sie fertig sind.

Eine private Klassenvariable bleibt "im Gültigkeitsbereich", solange sich die Klasseninstanz im Gültigkeitsbereich befindet. Dies kann ein Problem sein, wenn Sie vergessen, es zu löschen (z. B. auf null festlegen oder die Auflistung löschen), da alles, auf das die private Variable verweist, nicht als Garbage Collected erfasst wird. Wenn Sie auf diese Weise private Variablen verwenden, entfällt der Vorteil, den Sie mit einem Garbage Collector erzielen.

Der .NET-Speichermanager ist sehr gut für kurzlebige Objekte optimiert. Ich habe sehr wenige Situationen gefunden, in denen es sinnvoll ist, ein Objekt auf Methodenebene in den Klassenbereich zu verschieben, um Speicherzuordnung und Garbage Collector-Overhead zu vermeiden.

Ich werde den Ratschlag von @ dtb wiederholen: Verwenden Sie einen Profiler, um Engpässe zu finden und potenzielle Optimierungsmöglichkeiten zu identifizieren. Sonst stocherst du nur im Dunkeln herum und deine "Optimierung" wird sich wahrscheinlich negativ auf die Performance auswirken.

Answer 2

1) Variablen sind kein Müll gesammelt. Objekte sind. Deklarieren Sie Ihre Variablen immer im richtigen Bereich. Verwenden Sie einen Profiler, um Engpässe zu finden und Optimierungen zu bewerten, bevor Sie sie anwenden. Die Wartbarkeit für die Geschwindigkeit nicht vorzeitig aufgeben.

2) Wahrscheinlich. Verwenden Sie einen Profiler.