Performance

Dynamic Proxy adds two kinds of cost, both small:

• A one-time cost per proxied call site. The first time a proxied member is invoked, the injected resolver resolves the target and wires up the delegate. This happens lazily (only for call sites actually reached) and once per call site. In applications that proxy a very large number of distinct calls this can add a small, measurable amount to startup or first-use time.
• A negligible steady-state cost. After the first call, invocations go through the cached delegate. The added per-call overhead is on the order of a few nanoseconds and is irrelevant for the vast majority of code.

Because the body of the called method itself is unchanged, methods that do real work are unaffected in practice. The overhead only becomes noticeable for extremely small methods invoked in very hot loops (millions of calls). For those cases — and to keep startup fast when only part of the code is sensitive — use Filters to proxy just the calls that need protection rather than the whole assembly.

It’s important to note that while dynamic proxy protection provides an additional layer of obfuscation, it may have a slight impact on the startup time of your application due to the generation and initialization of the proxy classes. However, the trade-off between improved security and a small performance impact is generally considered worthwhile in most cases.