比较冷启动和热启动答案

【问题标题】：Comparing cold-start to warm start比较冷启动和热启动
【发布时间】：2010-09-12 17:24:16
【问题描述】：

与已经打开一次（热启动）相比，我们的应用程序在重新启动（冷启动）后启动所需的时间要长得多。

大多数（如果不是全部）差异似乎来自加载 DLL，当 DLL 位于缓存的内存页面中时，它们的加载速度要快得多。我们尝试使用ClearMem 来模拟重新启动（因为它比实际重新启动花费的时间要少得多）并且得到了好坏参半的结果，在某些机器上它似乎非常一致地模拟了重新启动，而在某些机器上却没有。

总结一下我的问题是：

您是否经历过冷启动和热启动之间的启动时间差异？
您是如何处理这些差异的？
您知道可靠模拟重启的方法吗？

编辑：

对 cmets 的说明：

应用程序主要是带有一些 .NET 的原生 C++（加载的第一个 .NET 程序集为 CLR 付费）。
我们正在寻求缩短加载时间，显然我们已经完成了分析工作并改进了代码中的热点。

我忘了提到的是，我们通过重新构建所有二进制文件得到了一些改进，因此加载器不必在加载时执行此操作。

【问题讨论】：

Motti，你对模拟重启有什么新想法吗？我也在为我们非常大的应用程序寻找这种方法，但没有找到可靠的方法
@Dbger，对不起，我没有在这方面取得任何额外的进展，我转向了不同的问题。祝你好运。

标签： windows performance reboot

【解决方案1】：

至于模拟重启，您是否考虑过从virtual PC 运行您的应用程序？使用虚拟化，您可以方便地一遍又一遍地复制一组条件。

我还会考虑使用某种类型的 profiling app 来发现导致时间延迟的代码位，然后判断该代码中有多少是真正需要的，或者是否可以以不同的方式实现.

【讨论】：

虚拟机的问题（我们使用 VMWare 而不是 Virtual PC）是它们对所有内容（包括 CPU）进行负载平衡，而我们得到的数字并不一致。
要点，尽管我怀疑通过复制重新启动您正在追逐症状而不是根本原因。事实仍然是，无论何时加载，DLL 中都会发生一些过于耗时的事情，硬重启只会加剧问题。我相信分析工具会在这里提供帮助

【解决方案2】：

很难在软件中真正模拟重启。当您重新启动时，您机器中的所有设备都会置位其重置位，这将导致系统范围内的所有内存丢失。

在现代机器中，内存和缓存无处不在：VM 子系统为程序存储内存页面，然后操作系统将文件内容缓存到内存中，然后你就得到了硬盘驱动器本身扇区的磁盘缓冲区。您可能可以重置操作系统缓存，但是驱动器上的磁盘缓冲区？我不知道有什么办法。

【讨论】：

【解决方案3】：

您是如何分析您的代码的？并非所有的分析方法都是平等的，有些方法比其他方法更好地发现热点。您是否正在加载大量文件？如果是这样，磁盘碎片和寻道时间可能会起作用。

甚至可能将基本的时间信息粘贴到代码中、写入日志文件并在冷/热启动时检查文件将有助于确定应用程序花费时间的位置。

如果没有更多信息，我倾向于将文件系统/磁盘缓存作为这两种环境之间的可能差异。如果是这种情况，那么您要么需要花更少的时间预先加载文件，要么找到更快的方法来加载文件。

示例：如果您要加载大量二进制数据文件，请将它们组合成一个文件来加快加载速度，然后一次读取整个文件到内存中并解析它们的内容。更少的磁盘寻道和读取磁盘的时间。同样，也许这不适用。

我不知道任何清除磁盘/文件系统缓存的工具，但是您可以编写一个快速应用程序来从磁盘读取一堆不相关的文件，从而导致文件系统/磁盘缓存加载不同的信息.

【讨论】：

我将研究统一 DLL，这听起来像是一个有前途的选择。
从症状看，好像是加载代码比较耗时，而不是初始化代码的执行时间。在这种情况下，分析器将无济于事（除非可能查看您是否在改善加载时间方面取得了进展）。减少必须加载的 DLL 数量，使它们更小，重新设置它们的基数，以免重叠。重新启动时访问注册表也很痛苦。

【解决方案4】：

@Morten Christiansen 说：

一种使应用程序更快地启动冷启动的方法（有点）被例如使用。 Adobe reader，通过在启动时加载一些文件，从而对用户隐藏冷启动。这仅在程序不应该立即启动时才可用。

这让客户在每次启动时都要为我们的应用程序的初始化付费，即使它没有被使用，我真的不喜欢这个选项（Raymond 也不喜欢）。

【讨论】：

【解决方案5】：

加快应用程序启动的一种成功方法是将 DLL 切换为延迟加载。这是一个低成本的改变（一些对项目设置的摆弄），但可以使启动速度显着加快。然后，在分析模式下运行depends.exe，以确定在启动期间加载了哪些DLL，并恢复它们的延迟加载。请记住，您还可以延迟加载所需的大多数 Windows DLL。

【讨论】：

【解决方案6】：

改善应用程序冷启动时间的一个非常有效的技术是优化函数链接排序。

Visual Studio 链接器允许您传入一个文件，其中列出了正在链接的模块中的所有函数（或只是其中的一些 - 不必是所有函数），链接器会将这些函数放在记忆中的彼此。

当您的应用程序启动时，通常会在整个应用程序中调用 init 函数。其中许多调用将针对尚未在内存中的页面，从而导致页面错误和磁盘查找。这就是慢启动的来源。

优化您的应用程序以使所有这些功能结合在一起可能是一个巨大的胜利。

查看 Visual Studio 2005 或更高版本中的配置文件引导优化。 PGO 为您做的一件事就是函数链接排序。

在构建过程中工作有点困难，因为使用 PGO，您需要链接、运行应用程序，然后与配置文件运行的输出重新链接。这意味着您的构建过程需要有一个运行时环境并在错误构建后进行清理等等，但回报通常是 10+ 或更多更快的冷启动，无需更改代码。

【讨论】：

谢谢，我去看看。顺便说一句，当您说 10+ 时，您的意思是 10%？

【解决方案7】：

作为函数顺序列表的替代方法，只需将要在相同部分中调用的代码分组：

#pragma code_seg(".startUp")
 //...
#pragma code_seg

#pragma data_seg(".startUp")
 //...
#pragma data_seg

随着代码的变化应该很容易维护，但与函数顺序列表具有相同的好处。

我不确定函数顺序列表是否也可以指定全局变量，但是使用这个#pragma data_seg 就可以了。

【讨论】：

【解决方案8】：

一种使应用程序更快地启动冷启动的方法（有点）被例如使用。 Adobe reader，通过在启动时加载一些文件，从而对用户隐藏冷启动。这仅在程序不应该立即启动时才可用。

另一个注意事项是，.NET 3.5SP1 据说已经大大提高了冷启动速度，虽然我不能说多少。

【讨论】：

这是邪恶的，也是我没有安装 Adobe 阅读器的原因之一。

【解决方案9】：

可能是 NIC（LAN 卡）并且您的应用依赖于某些其他需要网络启动的服务。因此，单独分析您的应用程序可能无法完全告诉您这一点，但您应该检查您的应用程序的依赖关系。

【讨论】：

事实并非如此，我们是纯粹的客户端。

【解决方案10】：

如果您的应用程序不是很复杂，您可以将所有可执行文件复制到另一个目录，这应该类似于重新启动。（剪切和粘贴似乎不起作用，Windows 足够聪明，可以知道移动到另一个文件夹的文件会缓存在内存中）

【讨论】：