提高Delphi的编译速度(bpl和bcp)

时间:2023-04-11 16:16:02

delphi的编译速度提高(一)

此博文为原创,转载请注明出处

作者 :二娃

此博文的内容我曾经回答群内和论坛内的网友提问时回答过,现在写第一部分,第二部分,我再给出一个终极的提高速度的方法

我用过delphi 7,delphi2005,2006,2007 现在零星地用用2009以及2010,但是无论用哪种版本,其中第三方控件是少不了的,可是随之而来的问题是,每多用一种类型的第三方控件,delphi的编辑和代码提示速度降低一些,到最后,像代码提示(实际上也是编译或者预编译)有时弹出提示内容竟要花去1分钟,急得直让人吐血

我现在将这种慢的地方例出来:

1.              编译时,Ctrl+F9或者F9,delphi将所有用到的单元pas编译成dcu中间文件,再将dcu组后成可执行文件(exe,dll,bpl)

2.              首次代码提示第1种情况后的首次代码提示,将此单元内的直接引用或间接引用到的其它单元统统编译成dcu存于内存或者解析dcu的内容存于内存,当编译再次编辑时,delphi先清除dcu解析缓存,从头再来.

3.              以上两种的慢慢的地方,主要是解析dcu文件开销,第二次代码提示则不需要,因为缓存内已经有解析好的dcu

要了解决上面的问题我先延伸出一个解释出来

bcp文件是bpl文件生成时的付产品,对于执行文件来说是没有什么用的,但是对于delphi作用可是少不得,是不可或缺的。bpl和dcp都是为都可以被delphi调用,但是调用的方式是不一样的。

bpl文件是执行调用:delphi(包括其它的exe)执行时直接访问bpl的地址,如果地址不存在,就会报错.

bcp文件是编译调用:delphi在编译时不访问引用的bpl的,访问的信息来自相应的dcp,,同一时期编译出来的dcp文件总是正确地记录相关bpl的地址,供delphi编译时通过.delphi编译执行文件时,不会检查bpl与bcp的版本是否一致,它只管读到bcp,因此不管相应bpl有无直正的地址即使bpl不存,dcp说有什么,在什么位置,delphi就完全相应它,编译通过,假如dcp文件没有相关地址信息,即使相应的bpl有,编译也通不过.

打个比方,bpl好像一个产品,提供特定的功能,dcp文件就好像bpl的产品说明书,delphi编译时就相当于生产,按说明书生产另一个配套产品(exe,dll,bpl), delphi调用bpl时就像把bpl组装到exe.dll上,由于exe,dll是根据说明书上生产来的,它就认为被组装的bpl一定有相关的结口,此时如果产品接口,型号不对,当然不能组装了

好了,理解了上面,我们可以这样解释:delphi编译文件时(提示框弹出也是一种编译,前面说过),先要准备说明书,如果说明书没有,就现场制作(解析dcu,如果没有dcu文件,就要从pas文件转换成dcp),慢就慢制作说明书这个过程,假如先把说明书提供给delphi,那么delphi就会再花上一段时间造说明书了,这段时间就会被节省下来,很简单,提供相关单元的bpl的dcp文件给它,那怎么提供呢?

打开工程:Project->Options->Packages->Build with runtime packages 钩上,

这样我们在写代码时,或者编译测试时,速度就会大大提高,原来要1分钟时间才弹出提示,现在还不1秒中.快了很多吧?

等到产品最要终于给用户时,再将Build with runtime packages 钩去掉,再编译一个完整的exe 给用户,这样就可以不带bpl了

如果不想去掉钩,就要把相应的bpl提示给用户,刚才说到的钩内的框内有很多说明书,但不是每种bpl对于最终用户使用exe都是必需的,我的经验是按我使用的控件,先大体把相应的bpl代到,一起考备到一个干净的机器上,然后运行exe,提示缺哪个再考哪个,

我倾向于后面一种文法,给相关的bpl,但是又会有一个问题来了,我在

《Delphi打包bpl暨delphi的编译速度提高(二)》中接着讲
Delphi打包bpl暨delphi的编译速度提高(二)

此博文为原创,转载请注明出处

作者 :二娃

在(一)种我讲到利用dcp文件提高delphi编译及代码提示速度的方法,最后抛出一个问题.

什么问题呢?假如我的工程是引用包编译的,那么就必需要提相应的bpl给用户,视程序用到的控件种类而定,从几个到几十个不等,这样就有一个效率的问题,比如只用到一个控件包中的一个控件,那么我也提供这组控件的完整的bpl包,那就显得太浪费,不是吗?毕竟你不是M$,每个产品发布时都要用DVD来,

exe文件小看起来漂亮,编译也快,也许我是一个完美主意者才这样说的.

如果你用过skype,在这里我给广大delphi爱好者打打气,skype是delphi写的,卖了43亿$,神吧?佩服吧?但我不喜欢skype编译出来的文件或者打包方式,skype提供给用户的就一个exe(08年时是14M多),我想编译skype的人一定很有恒心,14M呢,每次调试时都要花半天才能编译出来,写代码时,代码提示也是个问题。

如果有方法把exe内用到的所有控件单元单独打包成一个bpl或少量若干个bpl再加上一个exe文件,那这就太完美了,有没有方法呢?有,把程序本身的引用到单元单独提出来,至于间接引用到的单元可以不用管,单独制作一个bpl(dcp也一样)编译输入到exe存放的目录下,编译这个bpl时,delphi提示此bpl是否要此用到其它的bpl,要千万不要引用,否则就白做了. Project->Options->Packages->Build with runtime packages 钩上,在包内就加上你刚才的bpl名称(不带.后面的),OK了.

这样只有当我改动第三方代码时,我才要重新编译bpl,否则的话,这块的编译永远省略,速度那提高得没话说.

我自已制作了一个这样的ide工具,是从cnwizars基础上写的,用于自动查找工程或工程组中引用的单元,再将这些单元制作成bpl,但是由于tree的那部分用到商业控件,所以不能发布,等我有空件时改成免费控件时,再发布给相要的人使用.

用上面的方法,无论手动或自动制作的bpl,看上去很美,用起来也呱呱叫,但是紧接着问题就来了。那就是多线程的问题。网上有人提问过,我实际中也遇到过,

线程在bpl文件内使会时不时地出问题,而且出现的问题没有有规律,无法测试跟踪或者太难测试,原因当然不只是vcl控件不是线程安全的这一个原因这样简单。在bpl内,线程的waitfor等线程方法会无限制地等下去.程序也许可以启动,但退不出来,等等,我个人的理解bpl 还不是真正意义上的dll,在dll内Hintance有真正的实例,bpl则不是.所以线程退不出来。线程在地址上读写冲突.比如,loadbpl时,线程就开始工作,可是这时实例还没有创建....

线程不能在bpl内运行,或者运行不好,那有没有一种方法将线程提到bpl外运行呢.我之前的方法是将含有线程的代码不引用到bpl内,一个个单元区分,甚至改大量地改动第三控件的代码,但是随着使用深入,发现这种方法也太不现实,有时改动的第三方代码太多,再遇到含有线程的控件如果是基类的话,那区分的地方就更多了,经过我多次实验,我终于发现,只要线程的实例的创建不要由bpl内的代码直接创建就行,间接创建就不会有问题,经过多次的实践,最终证实是这样的, 明白了这个,那只需要稍微地改动一个第三方代码,问题就好办多了。下面简单举个例子

某bpl内单元种有一段创建线程的实例的地方:

(终极解决方法)

Unit Unitbpl

Interface

Use

…….

Implementation

procedure Createxxxthread;

begin

….

fxxxthread:= Txxxthread.create(someparams);

…..

end;

end.

我现在将上面的单元稍微改动成以下

Unit Unitbpl

Interface

Use

…….

TCreateThreadFun=Function(Somparms): Txxxthread;

Var

_CreateThreadFun: TCreateThreadFun=nil;

Implementation

procedure Createxxxthread;

begin

….

if @_CreateThreadFun<>nil then

fxxxthread:=_CreateThreadFun(someparams);

…..

end;

end.

接着我再写一个单元

Unit CreateThreadUnit

Interface

Use

Unitbpl;

Implementation

Function newCreateThreadFun(someparams): Txxxthread;

Begin

result:=Txxxthread.create(someparams);//线程实例在exe内创建

End;

Initialization

@ CreateThreadFun:= newCreateThreadFun //初始化时,这里填写地址

Finalization

@ CreateThreadFun:=nil; //也可以不要这一行

End.

//注意此单元直接此用到exe工程中引用了,千万不能放在bpl内,

以上方法经过千万的试验,线程没有任何问题。

http://www.vckbase.com/module/articleContent.php?id=4372