其它不说了，都在图上

为了再重现这个实验，我忘了备份专家包设置，版本你要给你加N多分才行

cnwizards是块玉，璀璨终有一天，
把CnFastCodeWizard放在首位，同时怎么想办法把fastcode放在CnFastCodeWizard首位，不然加了fastcode也等于没有优化,刚看了一下代码CnFastCodeWizard里的代码，不好移啊

东西不在多，而在精，建议cnwizards全部不动地使用fastcode或者完全不用
fastcode哪一句代码不是经过无数无名的作者耗费无尽的心血?
正因为有了这些代码才保住了pasical语言的完整地战胜了C语言
也保住了我们这些使用delphi的人的脸,
刚才又看了一下cnfastcode，原创的没几句，难道在前面加一个cn就能表示这个代码是。。。。。。。
感觉不仗义
对不起，我比较直接，

[ 本帖最后由 niaoge 于 2007-4-26 13:42 编辑 ]

从速度来讲，是应该尽量将fastcode放首位，但这个首位也只在CnWizards的DLL加载时的首位。
如果别的dll加载在前，还是可能和CnWizards的Fastcode冲突。

不会，我第二个例子就是delphispeed后启动的，重做了一个cnwizards的dll,把fastcode放在首位，然后关delphi,用新编译dll替换cnwizardsD11.dll，一点问题都没有，
所以说只要把fastcode放在cnwizards的首位就没有问题,
codefast只要放在首位会自动判断其它项目有没有加载fastcode,并能做出正确的替换

[ 本帖最后由 niaoge 于 2007-4-26 14:56 编辑 ]

我怎么成了普通灌水员？至少灌的也是加糖的水(请问版主哪一句不是精华？)，呵呵，
cnwizard没有正确地使用fastcode可能是导致慢的一个原因，其它dpr如果不放在首位倒没关系，但是cnwizards是一个变相的RTL,fastcode 有一句原话是RTL时必需放在首位,
第二点如果现在不改，那将不利于cnwizards的推广，今天delphispeeds会用fastcode,明天gexperts也会用,再假如madException也用，Eurokalog也用,那不乱套了，你是叫用户只装你一家工具?还是你把这些功能都做全？叫他们不用其它的工具，
上次为了测这个bug我至少将机子重装了两遍系统，直到从 cvs上下载原代码，我才知道是怎么回事
另外fastMM并不包含在delphi source的任何地方，只是delphi的某些IDE的dll,exe用fastMM编译过(别听老李哥瞎扯，delphi8,2005，好在哪里?2007到现在我至少找出2个重要的bug,在他眼里哪个不好？)，请将fastMM，sharemem也加进来，因为cnwizards很多地方与delphi内的dll.bpl,exe交换数据，没有这些真的独木难挣啊

[ 本帖最后由 niaoge 于 2007-4-26 14:13 编辑 ]

“普通灌水员”是一般用户的论坛头衔，根据发帖数来的。原先是英文，我改成中文了。
niaoge兄灌的确实不错，应该加分。不过我还是不明白“为啥fastcode放在CnWizards的头一个时能够自动判断其它项目有没有加载fastcode,并能做出正确的替换”，虽然Fastcode确实是应该尽量靠前。

看来得周兄也一块来研究一下。

fastcode内有hook,主要是替换同一exe系统内的原delphi原码内的如replacestring，等,他先加载是为了让delphi编译的相同的函数不起作用从而取而代之，如果他不放在第一位加载，实际上等于没加载或没加载全，并且，同一exe系统内的其它dll如果使用了fastcode将会出现寻址错误，也就是不能正确地判断要不要替换
不知我说的对不对？
另外fastMM也是相同的道理，他会替换delphi source内编译出的相关内存处理的函数或过程，fastMM也提供sharemem,但要在inc内开启，他只是提供sharemem相关方法，dpr工程内必需有sharemem这个pas,编译好的文件启动后,当用到sharemen内的几个函数时会从fastmm这里找方法而不是从delphi 原source编译的函数内找方法，
不能确定的话你可以编译一个带sharemem,一个不带sharemem,比较大小就知道了

[ 本帖最后由 niaoge 于 2007-4-26 15:07 编辑 ]

niaoge兄说的“一exe系统”，关键是CnWizards的DLL是后于exe本身加载的，因此即使即使CnFastCode在DLL这个dpr中第一个加载，同样也会比exe和其他先加载的DLL/BPL慢。

Fastcode似乎是有机制检测是否加载过而避免重复加载，这个可能是没有出现冲突的原因。

但niaoge兄贴图出的错误就不知道是FastCode哪儿出冲突问题了，或许CnWizards的DLL中尽早提前fastcode能够解决这个访问冲突问题也未可知。

那个图是刚加载delphispeedup时出错，我不能点确定，因为点了这个图就没有意议了，考，我没说明白，怪我，
因为cnwizard不是放在首位，可能只替换了一部分原delphi编译出来函数(vcl100)，结果delphispeedup跑上来了，因为cnwizards的fastcode不是在首位，他以为没有替换，就跑上来直接替，结果没找到地址，出现寻址错误，搞编程的一看到这个都知道是没找到对像，别忘了在delphi里，函数过程也是对像，
fastcode替换不是替换文件本身，而是从内存里将这一exe系统内加载到内存里的相关函数替换，看上图，000000应该是靠前的位，

第一、Fastcode的替换应该是都替换的，放后面放前面只是替换时刻的差异吧。
第二、你说fastcode正在替换到一半时时可能Delphispeedup跑上来，看见没替换的就替就会产生冲突，但我记得IDE加载DLL/BPL等并不是多线程的，也就说IDE启动时这两者的替换动作貌似不太可能并行。

CnWizards明确地声明了是使用第三方的FastCode而不是原创的啊，专家的作者和帮助中都写着FastCode Project的名字，而且FastCode本身的代码、文档和协议也完整带上，没有做改动！

之所以单独写一个CnFastCode而不是直接用FastCode，是因为在IDE中使用时FastCode单元不能正常工作。FastCode.pas中对rtl打补丁是静态的，而且最重要的是CnWizards使用的rtl函数都来自rtl.bpl，需要用GetBplMethodAddress转成bpl中真实的函数入口地址才能真正把FastCode的函数补丁上去，否则我们也不会重新写一个CnFastCode了。

CnWizards和DelphiSpeedUp两个专家的加载顺序是不一样的，DelphiSpeedUp通过在Known IDE Packages注册表项中加载DelphiSpeedUpLoader7.bpl，将FastCode尽可能早的加载。而CnWizards是作为Experts项加载的，比DelphiSpeedUp要晚很多，所以对ide启动性能的改进不大。

另外，FastCode的加载也不同于FastMM。FastCode的加载是一个Hook RTL函数的过程，虽然文档上要求放最前面，但是从理论上讲不一定非得放在工程的最前面（如果不考虑多线程安全的话），而FastMM由于替换的是内存管理器，所以必须放最前面。

刚才还没看见niaoge兄的这段。
是啊，提这种意见前，得仔细看看，不要随便就定性为不厚道。

你们的DelphiSpeedUp的版本是多少？我记得后来的DSU曾经为CnPack做了一个更新的，应该可以并存的

呵呵，我说话比较直接，不会拐湾抹角，刘总，周总，得罪了

我觉得直接用CnWizards好了，免得再安装DelphiSpeedUp

已找出解决方法,cnfastcode也可以正常使用,方法发送至周总，待他白天再测试

我觉得在D2007以后的版本可以不用再加载FastCode代码了,因为很多FastCode代码已经加载到Delphi的RTL标准代码中,使用FastCode代码替换,反而多余,不会产生什么显著效益,可能反而造成兼容性问题