依赖注入启动性能答案

【问题标题】：Dependency Injection Startup Performance依赖注入启动性能
【发布时间】：2010-12-23 01:56:10
【问题描述】：

我最近被要求对使用 Microsoft 的 Composite UI Application 块构建的应用程序中的一些性能问题进行故障排除 - 特别是加载时间过长。

这是围绕微软的 ObjectBuilder 依赖注入框架构建的，它使用反射/属性来注册类。分析表明，应用程序在启动时会花费大量时间进行反射，因为 ObjectBuilder 会扫描每个加载的程序集中的每种类型以搜索要注册的内容。

其他 DI 框架似乎也都使用属性、XML 配置或纯代码。
似乎没有任何其他基于属性的框架会更好，而且我对必须解析大量 XML 等的启动时间持怀疑态度。
基于纯代码的框架看起来应该快得多，但它们的灵活性也差很多，所以看起来并不是一个明确的好选择......

这导致我搜索 DI 容器基准，但我唯一能找到的是这个：http://www.codinginstinct.com/2008/04/ioc-container-benchmark-unity-windsor.html。
虽然它是一个很好的基准，但它只衡量使用容器创建 100 万个对象的速度。我对创建 100 万个对象没有兴趣，我只是希望应用程序尽快启动，所以我正在寻找有关 DI 容器启动成本的任何信息，无论是博客文章，轶事，甚至像“这是一种让 ObjectBuilder 更快的方法”这样简单的东西。

提前致谢

【问题讨论】：

标签： .net dependency-injection benchmarking

【解决方案1】：

您是否尝试过在所有程序集都经过 NGEN 后测量启动时间？我发现（至少在 IronScheme 中）它在反射场景中有很大帮助（在我的情况下从 1.5 秒到 0.1 秒）。

【讨论】：

同意，很多时候是由于每个班级的JIT。
据我所见，NGen 对反射性能的影响可以忽略不计，而这正是导致速度下降的原因。
我没有尝试过 NGEN，但我不确定这是否是一个好主意 - 有问题的应用程序是 ClickOnce 部署的客户端应用程序，不必进行任何操作GAC 将被 NGEN 化？

【解决方案2】：

关于让它更快...

我认为可能有一种方法可以缓存启动结果。也许应用程序会花费更多时间来进行反射，然后缓存结果，但是在您第二次启动时，如果没有任何变化，您可以从缓存中加载（这可能会更快）。

至于这个缓存的性质，可能是对象被序列化到磁盘上。作为“没有改变”的问题，初创公司可以查看校验和。

【讨论】：

【解决方案3】：

我不了解 ObjectBuilder，但最近的依赖注入框架通常支持延迟加载以提高启动性能。例如，请参阅Lazing Around with Autofac2。

或者您可以像 Ploeh 的 LazyOrderShipper 示例中那样手动完成。

【讨论】：