CLR全面透彻解析: 提高应用程序启动性能

CLR全面透彻解析: 提高应用程序启动性能2011-10-24 msdn Claudio Caldato由于等待应用程序启动是令许多用户都感到沮丧的一件事情，因此，侧重于提高客户端应用程序的启动性能将极大增强客户的第一印象，并使他们对您的努力成果印象深刻。同时，鉴于启动性能对用户非常重要，所以值得研究一下其影响因素，这样才能避免最常见的错误。

应用程序启动通常分为冷启动和热启动。在托管应用程序环境中，冷启动是指 Microsoft® .NET Framework 系统程序集和应用程序代码均不在内存中时，因而需要从磁盘提取它们。热启动则是指应用程序的后续启动，或者当大部分系统代码因之前由另一托管应用程序使用而已经存在于内存中时的应用程序启动。

冷启动

在大多数情况下，冷启动受 I/O 限制。换句话说，等待数据花费的时间长于处理指令所用的时间。启动应用程序所用时间等于操作系统从磁盘提取代码所用时间与执行其他处理（如对 IL 代码执行 JIT），以及在应用程序启动路径中执行的任何其他初始化所用时间的总和。由于处理通常并不是冷启动的瓶颈，因此，所有应用程序启动性能调查的初始目标都是通过降低加载的代码量来减少磁盘访问。

写入应用程序代码的方法对冷启动也有着重要影响，所以弄清楚下列情况非常重要，如启动时应用程序是否打开其他文件或者启动可能会争夺 I/O 资源的其他进程。

由于冷启动是受 I/O 限制的情形，因此使用传统的 CPU 分析器（无论是基于检测还是基于采样）对调查并无显著帮助。基于检测的分析器将等待 I/O 所用的时间报告为阻塞时间。问题是，即使您能够将阻塞时间归因于某个特定调用堆栈，阻塞时间也仅计一次。之后的所有磁盘 I/O 都会被忽略，从而导致将磁盘 I/O 的部分实际时间当成了总执行时间。

使用基于采样的分析器时，所收集信息甚至可能会产生误导。它跟踪的是 CPU 使用率而非 I/O，因此，在分析器的报告中不会记录 I/O 所用的总时间。

可通过图 1 切身体会一下冷启动由于连续两次启动应用程序而受 I/O 限制的情况。第一次启动很可能比第二次启动慢很多（在第二次启动时，由于第一次启动的原因，执行所需的大部分代码均已存在于内存中，因而避免了磁盘访问并节省了时间）。当然，要确保第一次启动是真正的冷启动，首先需要重新启动计算机，并确保在用户登录时启动文件夹中无托管应用程序，并且没有使用托管代码的 Windows® 服务在运行。

Figure 1 冷启动中的磁盘读取时间和 CPU 时间