Leistung

Dynamic Proxy verursacht zwei Arten von Kosten, beide gering:

• Einmalige Kosten je Aufrufstelle mit Proxy. Wenn ein über einen Proxy geleiteter Member zum ersten Mal aufgerufen wird, löst der eingefügte Resolver das Ziel auf und verbindet den Delegaten. Das geschieht verzögert (nur für Aufrufstellen, die tatsächlich erreicht werden) und einmal je Aufrufstelle. In Anwendungen, die sehr viele verschiedene Aufrufe über Proxys leiten, kann sich die Zeit für den Start oder die erste Verwendung dadurch um einen kleinen, messbaren Betrag verlängern.
• Vernachlässigbare Kosten im laufenden Betrieb. Nach dem ersten Aufruf laufen die Aufrufe über den zwischengespeicherten Delegaten. Der Mehraufwand pro Aufruf liegt in der Größenordnung weniger Nanosekunden und spielt für den weitaus größten Teil des Codes keine Rolle.

Weil der Rumpf der aufgerufenen Methode selbst unverändert bleibt, sind Methoden, die echte Arbeit leisten, in der Praxis nicht betroffen. Der Mehraufwand wird nur bei extrem kleinen Methoden spürbar, die in sehr intensiv durchlaufenen Schleifen aufgerufen werden (Millionen von Aufrufen). Verwenden Sie in diesen Fällen Filter, und ebenso, um den Start schnell zu halten, wenn nur ein Teil des Codes sensibel ist. So leiten Sie nur die Aufrufe über Proxys, die Schutz brauchen, und nicht die ganze Assembly.

Beachten Sie: Der Schutz durch dynamische Proxys bietet zwar eine zusätzliche Verschleierungsebene, kann aber die Startzeit Ihrer Anwendung geringfügig verlängern, weil die Proxy-Klassen erzeugt und initialisiert werden müssen. Der Tausch von besserer Sicherheit gegen eine kleine Leistungseinbuße lohnt sich jedoch in den meisten Fällen.