performance - 如何减少 VB6 项目启动时间/查明是什么花了这么长时间

Question

我使用两个 vb6 应用程序。其中一个启动速度非常快，而另一个则需要相当长的时间。我想我应该做一些分析来找出为什么需要这么长时间。

所以我从一开始就按 F8 启动，我意识到启动时间的很大一部分实际上是在我按 F8 的时间和它突出显示第一行代码的时间之间。

以下哪项最有可能导致此问题？

• 依赖项数量
• 组项目中有太多项目，而不是将它们作为 dll 引用
• 表单数量
• 启动表单中的对象数量
• 所有表单上的对象数量
• 还有什么？

作为额外的奖励，如果问题可能存在于多个领域，我希望能够提供有关如何更具体地查明问题的任何想法。

谢谢!

编辑:看来我可能还不够清楚到底是在“哪里”发生了减速。因此，为了清楚起见，我创建了以下过程:

Sub Main()
End Sub

就是这样，它位于一个除了这两行之外绝对不包含任何内容的模块中。没有加载任何表单，虽然还有其他模块带有“Dim o as New SomeObject”，但我知道这些对象没有被实例化，因为我知道 Visual Basic 不会创建以这种方式声明的对象，直到您实际使用它们第一次。

我相信我现在已经在技术上尽可能地优化了启动代码。但启动时间仍然相同。

编辑 2:我刚刚意识到编译的应用程序实际上启动得相当快。只是在ide中启动它需要很长时间。然而，我比客户更关心我的速度，因为他们只启动一次，然后让它运行一整天，而我每天启动几十次。

Answer 1

由于您提到您正在使用 Sub Main，因此延迟发生在加载任何表单之前，最有可能的可能性是问题出在您链接的 DLL 的初始化例程中。

每个 DLL 都会导出一个入口点函数(通常 DllMain )，该函数在 DLL 链接后立即调用。在 VB6 中，这将在执行 Sub Main 之前。

正是由于这个原因，DLL 作者在 DllMain 中做任何重要的事情通常是非常糟糕的形式，但许多懒惰的 DLL 开发人员在他们的 DllMain 中做了各种工作，这些工作实际上并不需要等到以后才能完成。如果您能找出罪魁祸首并重写它，那就可以解决您的问题。如果你不能重写它，你至少可以找到一种动态加载DLL而不是链接它的方法。

您还可以做一件事来加快任何依赖大量 DLL 的 Windows 应用程序的启动时间，即 rebase all the DLLs 。

EXE 和 DLL 被编译为假定它们将被加载到内存中名为 Preferred Load Address 的某些起始地址处。 。例如，DLL 可能包含指定要跳转到的绝对地址的 JMP 指令(基本上是 GOTO)。 DLL 文件本身会在开头包含一条小指令，对 Windows 说:“嘿，我希望我将从内存地址 X 开始加载，因为我的代码包含一堆指向假定位置的 JMP”相对于地址 X。”所以现在Windows会尝试将该DLL放在位置X处。但是如果其他东西已经在使用该空间，它别无选择，只能将其放在其他地方，称之为Y。当发生这种情况时，Windows必须遍历整个可执行镜像DLL 并将所有“X+n”形式的地址替换为“X+n+Y-X”...这称为 rebase ，速度很慢。

如果您事先知道某个 DLL 将与您自己的应用程序中的另一个 DLL 一起加载，则可以通过对所有 DLL 进行预 rebase 以使它们不连续，从而显着增加启动时间。