Ich beschäftige mich gerade damit, eine fließende Schnittstelle für eine existierende Technologie zu implementieren, die Code ähnlich dem folgenden Snippet erlauben würde:
%Vor% Um solche Konstrukte zu implementieren, werden Klassen benötigt, die Argumente akkumulieren und an andere Objekte weitergeben. Um beispielsweise das Konstrukt Open.File(...).In(...) zu implementieren, benötigen Sie zwei Klassen:
Das heißt, je mehr konstituierende Teile Anweisungen wie die ersten Beispiele haben, desto mehr Objekte müssen erstellt werden, um Argumente an nachfolgende Objekte in der Kette weiterzugeben, bis die eigentliche Anweisung schließlich ausgeführt werden kann.
Ich bin an einigen Meinungen interessiert: Beeinflusst eine flüssige Oberfläche, die mit der oben genannten Technik implementiert wird, die Laufzeitleistung einer Anwendung, die sie verwendet? Bei der Laufzeitleistung beziehe ich mich auf beide Geschwindigkeits- und Speicherauslastungsaspekte.
Bedenken Sie, dass eine potentiell große Anzahl von temporären, argumentsparenden Objekten nur für sehr kurze Zeitspannen erstellt werden müsste, von denen ich anmaße, dass sie einen gewissen Druck auf den Garbage Collector ausüben.
Wenn Sie glauben, dass es erhebliche Auswirkungen auf die Leistung hat, kennen Sie einen besseren Weg, um fließende Schnittstellen zu implementieren?
Im Allgemeinen sind Objekte mit einer sehr kleinen Lebensdauer genau die Art von Objekten, mit denen der GC am effizientesten umgeht, weil die meisten zum Zeitpunkt der nächsten kleinen Sammlung tot sind - und bei jeder vernünftigen GC-Implementierung, Die Kosten für eine kleinere Sammlung sind proportional zur Gesamtgröße von live Objekten. So kosten kurzlebige Objekte sehr wenig, und ihre Zuweisung bedeutet nur, einen Zeiger hochzustoßen, was schnell ist.
Also würde ich sagen: wahrscheinlich keine signifikanten Auswirkungen auf die Performance.
Thomas ist ziemlich richtig, dass Generations-GC für genau diese Zuordnung und Sammlung von kurzlebigen Objekten optimiert ist. Allerdings haben funktionale Sprachen wie OCaml GCs, die dafür viel stärker optimiert sind als .NET, und dennoch unternehmen sie immer noch große Anstrengungen, um diese Situation zu umgehen, indem sie mehrere Argumente auf eine Curry-Funktion anwenden. Insbesondere verwenden sie eine Technik, die als Big-Step-Semantik bezeichnet wird, bei der der Compiler alle Intermediate zur Kompilierungszeit entfernt, so dass der GC niemals etwas davon sieht.
Unter .NET können Werttypen das Problem möglicherweise selbst lösen.
Tags und Links .net garbage-collection performance runtime fluent-interface