问冷启动优化

EN

有一件事可能会有帮助，那就是看一看概要导引优化，它会重新排序可执行文件，以便以最有效的顺序加载。

但实际上，你应该试着找出时间的去向-听起来可能要进行大量的磁盘访问-你加载了大量的大数据(图像等)吗？这似乎不太可能是纯粹的代码加载，这需要花费这么多时间。

你有没有尝试过像Procmon (www.sysinternals.com)这样的工具来查看哪些文件被触动了？

长时间冷启动是纯粹的硬盘问题。查找程序所需的DLL。除了运行碎片整理工具之外，您无法优化硬盘。对程序进行分段以使DLL加载与UI时间重叠是相当困难的。使用COM服务器或链接器的/DELAYLOAD选项是显而易见的方法，但在不接触任何东西的情况下将功能UI显示在屏幕上并不是那么容易。将类分离到由工具栏或菜单选项触发的DLL中当然是可能的，但MFC不会让空闲时间UI更新变得那么容易(对不起，忘记了确切的短语)。

你不是一个人，Microsoft Office和Acrobat Reader就是一个很好的例子。他们用一个非常棘手的技巧解决了这个问题，他们在Run注册表项或Startup文件夹快捷方式中安装了一个“优化器”。它不做任何事情，只是接触所有的all，以便将它们加载到文件系统缓存中。在用户检查她的电子邮件后，给EXE一个热启动。我讨厌它们，在他们把它们放回原处后，我一直在删除它们。但它确实改善了用户的意见，他们会认为是电子邮件阅读器速度慢。当然，还有那该死的Windows-Mac a-Mac。

也就是说，30秒是一个非常长的时间。一定要确保这不只是你的开发机器上的问题，这是由于一遍又一遍地构建二进制文件并将它们分散在磁盘上而引起的。运行碎片整理程序。接下来，检查它对SysInternals的ProcMon实用程序所做的一切。

“我今天试着尝试使用延迟加载链接器设置，但我不太理解它们如何影响性能。”

当您链接到DLL依赖项时，它会预先加载它-在第一次加载可执行文件时。延迟加载就像它所暗示的那样，延迟加载，直到真正需要它时-当DLL中的一个类型或方法第一次被可执行文件使用时，即您可以将其视为模块级的lazy initialization。

链接器有效地将存根用于LoadLibrary和GetProcAddress。一旦加载了DLL，存根就会被覆盖，这样从那时起就可以直接调用DLL了。

要利用这一点，您需要查看代码路径-哪些变量或方法调用在主屏幕上有条件地使用或不使用，在这种情况下，它们不需要预先加载。