我使用了两个vb6应用程序.其中一个启动非常快,而另一个需要很长时间.我想我会做一些分析,找出为什么这么长时间.
所以我在开始时按F8开始,我意识到启动时间的很大一部分实际上是在我点击F8的时间和它突出显示第一行代码的时间之间.
以下哪项最有可能造成这种情况？
作为奖励,我会喜欢任何有关如何更具体地确定问题的想法,如果它可能在多个领域.
谢谢!
编辑:似乎我可能还没有完全明确"减速发生在哪里".所以要说清楚我创建了以下过程:
Sub Main()
End Sub
就是这样,它在一个模块中除了这两行之外绝对没有任何内容.没有表单被加载,虽然还有其他模块"Dim o as New SomeObject",但我知道这些对象没有被实例化,因为我知道visual basic不会创建以这种方式声明的对象,直到你实际使用它们为止第一次.
我相信我现在已经在技术上尽可能地优化了启动代码.但它仍然需要相同的启动时间.
编辑2:我刚刚意识到编译的应用程序实际上启动速度相当快.它只是在需要很长时间的ide中启动它.然而,我对我的速度比对客户的关心更多,因为他们只是启动一次并让它一整天都在运行,而我每天都会开始几十次.
由于您提到您正在使用Sub Main,因此在加载任何表单之前发生延迟,最可能的问题是问题出在您链接的DLL的初始化例程中.
每个DLL都会导出一个入口点函数(通常是DllMain),它在链接DLL后立即被调用.在VB6中,这将在Sub Main执行之前执行.
由于这个原因,DLL作者在DllMain中做任何重要的事情通常都是非常糟糕的形式,但是许多懒惰的DLL开发人员在他们的DllMain中做了各种各样的工作,直到后来才真正做到.如果你能找出罪魁祸首并重写它,这将解决你的问题.如果你不能重写它,你至少可以找到一种动态加载DLL而不是链接它的方法.
还有一件事可以做,以加快任何依赖于大量DLL的Windows应用程序的启动时间,即重新安装所有DLL.
编译EXE和DLL以假定它们将在称为首选加载地址的某些起始地址处加载到内存中.例如,DLL可能包含指定要跳转到的绝对地址的JMP指令(基本上是GOTO).DLL文件本身在开头会包含一条指示Windows的小指令,"嘿,我希望我将从内存地址X开始加载,因为我的代码包含一堆JMP到假设的位置相对于地址X." 因此,现在Windows将尝试将该DLL放在X位置.但是如果其他东西已经在使用该空间,它别无选择,只能把它放在其他地方,称之为Y.当发生这种情况时,Windows必须通过整个可执行映像的DLL并将"X + n"形式的所有地址替换为"X + n + YX"......这称为变基,它很慢.
如果您事先知道DLL将在您自己的应用程序中加载另一个DLL,则可以通过预先重新定义所有DLL以使它们不连续来显着增加启动时间.