【发布时间】：2016-12-13 14:14:04
【问题描述】：
我一直在寻找一些关于典型 AOP 任务的性能测试。但是我一直找不到，你能帮帮我吗？ 我主要考虑的是 Castle、Unity，也许还有 PostSharp，尽管它对我的项目来说可能太贵了。
【问题讨论】：
-
定义性能测试。编译时间还是运行时间？
-
PostSharp 实际上将您的方面编织到您的代码中。不涉及任何实际的 AoP 开销。
【发布时间】：2016-12-13 14:14:04
【问题描述】：
我也没有看到任何定量比较，所以这个答案可能还远远不够。
很难将 Castle 或 Unity 的性能与 PostSharp 进行比较 - Castle 和 Unity 通过动态代理使用 runtime weaving，而 PostSharp 增加了开销 at compile stage。因此，如果性能对您来说至关重要，那么像 PostSharp 这样的编译解决方案总是会更好。在运行时生成 AOP 代理意味着动态生成 IL 代码和大量使用反射。
因此，可能有意义的性能测试必须比较使用相同技术的解决方案 - 您可以尝试比较 Castle Dynamic Proxy 和 Unity Interception 代理实现。
我不太了解前者，但在后者的情况下，仍然有三种不同的场景可供比较 - 透明代理 (MarshalByRefObject)、接口代理和子类代理 - 每个都有自己的一组使用场景和它自己的性能开销。根据我的阅读，透明代理非常慢，不应该在 AOP 场景中使用。接口和子类型代理会即时生成一些 IL，这与 Castle DP 所做的相同，所以我认为差异不应该那么大（但同样，这里没有量化结果）。
【讨论】：
如果你正在寻找一个轻量级的 AOP 工具，有一篇文章“使用动态装饰器为对象添加方面”（http://www.codeproject.com/KB/architecture/aspectddecorator.aspx）。它又薄又灵活。
它描述了一种在运行时向对象添加方面而不是在设计时向类添加方面的方法。这种方法的优点是您可以在使用对象时决定是否需要一个方面。
当今的大多数 AOP 工具在类设计时定义类级别的方面。当你使用类的对象时，你没有灵活性。
【讨论】：
如果性能在您的项目中至关重要，请确保您对 AOP 的使用是面向性能的，因为除非使用不合规，否则 AOP 框架的开销很少会很差。
例如，如果您使用 DynamicProxy，您可以选择使用反射或调用 Proceed() 方法来调用支持处理。它会改变不同的性能。
另一个例子：大多数 AOP 框架都会给你 MethodInfo 来给你的“建议”。他们获取此元数据的方式可能会改变您的性能，因为 GetMethodFromHandle 在极端并发处理（带锁的字典访问）中可能非常糟糕。
要记住的另一件重要事情是：为 Advice 方法使用适应的重载，因为如果 AOP 框架必须准备太多信息（参数、方法信息、...），您将付出代价（性能开销）。不幸的是，如果拦截是完美的，有时没有好的用户端界面来实现性能建议事件。
更多细节，在when-is-aop-code-executed的帖子中，我给出了关于AOP Framework性能问题的反馈。
【讨论】：