(Dies ist über eine Frage auf Twitter, hier mit Erlaubnis erneut gefragt)
Ich versuche, einige Objekte schnell zu validieren (um Nullen zu testen), und ich dachte, FastMember könnte vielleicht helfen - bei den unten gezeigten Tests sehe ich jedoch eine viel schlechtere Leistung. Mache ich etwas falsch?
%Vor%Das Hauptproblem hier ist, dass Sie die einmaligen Kosten der Meta-Programmierung innerhalb des Timings einschließen. FastMember verursacht einen gewissen Overhead, während es die Typen verarbeitet und eine geeignete IL erzeugt, und natürlich: Alle IL-Erzeugungsschichten benötigen dann zusätzlich JIT. Also ja, einmal benutzt: FastMember mag teurer erscheinen. Und in der Tat würden Sie etwas wie FastMember nicht benutzen , wenn Sie diese Arbeit nur einmal machen würden (die Reflexion wäre in Ordnung). Der Trick besteht darin, alles einmal (in beiden Tests) außerhalb zu tun, so dass die Leistung des ersten Laufs die Ergebnisse nicht beeinflusst. Und in der Leistung müssen Sie die Dinge normalerweise viel öfter als einmal ausführen. Hier ist mein Rig:
%Vor%Was fast-member ein bisschen schneller zeigt, aber nicht so viel, wie ich es gerne hätte - 600ms (Reflektion) vs 200ms (FastMember); wahrscheinlich ändert die 1.0.11 die Tendenz zu großen Klassen zu stark (die Verwendung von 1.0.10 dauert nur 130ms). Ich könnte eine 1.0.12 veröffentlichen, die verschiedene Strategien für kleine vs große Klassen zum Ausgleich verwendet.
Aber! Wenn Sie in Ihrem Fall nur null testen möchten, würde ich ernsthaft in Erwägung ziehen, diesen Fall direkt über IL zu optimieren.
Zum Beispiel dauert der folgende Test nur 45 ms für denselben Test:
%Vor%mit:
%Vor% und ein einigermaßen verrückter Meta-Programmiercode, der den Test für jede gegebene T an einem Ort durchführt:
Tags und Links .net fastmember