AOP性能开销

Question

我一直在寻找一些关于典型AOP任务的性能测试。我找不到任何东西，你能帮助我吗？ 我主要考虑的是Castle，Unity和PostSharp，尽管它对我的项目来说可能太贵了。

Answer 1

我也没有看到任何定量比较，所以这个答案可能还远未完成。

很难比较Castle或Unity与PostSharp的性能 - Castle和Unity使用runtime weaving通过动态代理，PostSharp增加了开销at compile stage。因此，如果性能对您至关重要，PostSharp等已编译的解决方案将始终更好。在运行时生成AOP代理意味着动态生成IL代码和重反射使用。

因此，有意义的性能测试必须使用相同的技术比较解决方案 - 您可以尝试比较Castle Dynamic Proxy和Unity Interception代理实现。

我不熟悉前者，但在后者的情况下，还有三种不同的情景需要比较 - 透明代理（MarshalByRefObject），接口代理和子类代理 - 每个都有自己的用法集场景及其自身的性能开销。从我所读到的，透明代理非常慢，不应该在AOP场景中使用。接口和子类型代理会动态生成一些IL，这与Castle DP所做的相同，所以我认为差异不应该太大（但同样，这里没有定量结果）。

Answer 2

如果您正在寻找轻量级AOP工具，那么有一篇文章“使用Dynamic Decorator向对象添加方面”（http://www.codeproject.com/KB/architecture/aspectddecorator.aspx）。它薄而且灵活。

它描述了一种在运行时向对象添加方面的方法，而不是在设计时向类添加方面。此方法的优点是您可以在使用对象时确定是否需要方面。

今天的大多数AOP工具在课堂设计时定义课堂级别的方面。当你使用类的对象时，你没有灵活性。

Answer 3

如果项目中的性能非常重要，请确保您对AOP的使用是面向性能的，因为除非使用不合规，否则AOP Framework的开销很少很少。

例如，如果使用DynamicProxy，则可以选择使用反射调用支持处理或调用Proceed（）方法。它改变了不同的表现。

另一个例子：大多数AOP框架为您的“建议”提供MethodInfo。他们获取此metedata的方式可能会改变您的性能，因为GetMethodFromHandle在极端并发处理（带锁的字典访问）方面可能非常糟糕。

要记住的另一个重要事项是：使用适应性过度的建议方法，因为如果AOP框架必须准备太多信息（参数，方法信息，...）你将支付它（性能开销）。不幸的是，如果拦截是完美的，有时候没有良好的用户端界面来实现高效的建议事件。

有关详细信息，请在帖子when-is-aop-code-executed中提供有关AOP框架性能问题的反馈意见。