晚上把cnwizards 里的关于I*reader 和 I*writer 的结口的局部变量创建不用时作 :=nil处理
发现delphi的内存一点都不增加,，打开进程看,每刚输一个字后delphi内存增加几K,输入完成后delphi内存降到原来大小，2个小时过去了，同样的代码，delphi2007的内存还是维持在100M左右,没有开任何内存清理软件(以前可是不到一个小时可就直冲400，500M......直到做不动时强行关delphi ),原来delphi创建的的接口变量虽然没有实例，但是也要释放的,哈哈^_^.
还有一个助手的Items排序稍作了判断优化，发现助手除首次一样外其它弹出速度都很流畅.
delphi调用接口参见 http://www.openitpower.com/wenzhang/97/10449_1.html
班门弄斧一下，没有特地研究过delphi的接口性质.只是希望对cnwizards有帮助
周总，刘总.......,我不知道是不是真的管用.如果不是那真是献丑了,(对了，我还加了FastMM,FastCode)


不是很自信，附件是编译后的dll for 10,11，有兴趣的同行先试试看,如确实如上所说，马上把代码交上来。


2007/4/23  8:10
再经过优化，助手在 delphi2007 ,2006 里 弹出速度(包括首次，测试用一页6000行的代码)大大提高，主要是代码助手Item获取后过滤及排序判断(循环内减少重复计算，每按一个键有上千次的循环哟).再由于接口适时的释放，delphi退出速度非常快,也不会出现退出异常,
下面我再打包的两个dll for 10,11(分别用D2006,2007制作),赶快试吧（把这两个dll考到cnwizards的安装目录下覆盖原来的dll.覆盖前选备份一下原dll，用308的原码改制不会与现有的设置冲突）
）.呵呵，

[ 本帖最后由 niaoge 于 2007-4-23 09:38 编辑 ]

能否把修改过的代码贴上来看看？

代码超过了2M,只传source里的，并且把thirdparty里的全册了，
如果有错误，不要笑话我啊,

忘了,cnwizards\Source\IdeEnhancements\CnInputHelper.pas 少了一句话，重新加一个单独的附件

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

这么大？那改动过多少文件呢？
可否只把改过的文件传上来？

谢谢了。

刚看了一下，是不是只改过CnInputHelper.pas?

你用Beyond Compare比较一下，有好几个文件,我用codesite在循环时做判断调试,不要笑话啊
用codesite4 这样调试单元非常方便，安装codesite4到delphi2006下(如果delphi2007用到的话，加上codesite的路径到D2007里,)将下面附件里的csos.pas解压后将路径加到delphi路径下,
需要调试的单元，引用csos,
输出时直接   rc4.send......   想输出什么就什么（我自己发明的^_^）
以前做过彩票筛选玩玩，别看这小的循环一次判断无所谓，上千,万次性能非常影响大，

[ 本帖最后由 niaoge 于 2007-4-23 11:31 编辑 ]

按理说，Delphi对局部变量中的接口、动态数组、字符串等带引用计数的变量会自动初始化和自动释放的，所以CnWizards中局部创建的那些Reader等接口都没有显式的释放。比如在 Delphi 中写一个简单的例子：
procedure Test;
var
  Intf: IInterface;
begin
  Intf := TInterfacedObject.Create as IInterface;
end;
在CPU窗口中执行，最终会发现调用到了Intf._Release，而且Delphi自动生成了类似于 try...finally.end 的代码来实现清理保护。

niaoge 提到的问题很奇怪，看来得好好测试一下才行。

TortoiseCVS 有一个“生成补丁文件”的功能，可以用它来生成源码补丁，补丁里面还带有版本信息，我们可以直接应用到CVS中去。niaoge下次可以试试。

针对助手中的代码：      
CnOtaSaveReaderToStream(View.Buffer.CreateReader, Stream, StartPos,
    CurrPos + csParseBlockAdd, 0, False); // D2005 下不做 Utf8->Ansi 转换以免错位
的情况，又写了个测试：
function CreateIntf: IInterface;
begin
  Result := TInterfacedObject.Create as IInterface;
end;

procedure Test(Inf: IInterface);
begin
  ;
end;

procedure Test1;
begin
  Test(CreateIntf);
end;
同样，在 Test1 执行完成后也会自动清理 CreateIntf 创建出来的接口。

我哪里有那么深的水平，你看我发表的贴子大部分跟速度有关，以前同样的设置，第三方控件常用的还是装了很多，不过作天晚上工作几个小时，delphi明显没有一点停滞,比住常快很多N倍，象用记事本一样，内存也不升上，我机子上2G的内存，以前(确定没有病毒,也没有流氓，可以人格担保)，dephi2007工作不要半个小时的时间400,500M(主要是写代码和编译,界面设计好像内存不会长),再一会内存不够升了，总内存到1.62G(不全是delphi2007占用的)时dephi就不动了，看进程里，所有的进程占用的内存全加起来也不到1.62G,奇怪，而且好像还少几百M，奇怪，那几百M上哪里去了，而且delphi退出时还有经常有异常

[ 本帖最后由 niaoge 于 2007-4-23 12:00 编辑 ]

我曾经用到和修改过TEmbeddedWB源码,这是一个类似于TWebBrowser的控件，可想而知，里面引用的接口多如牛毛，记得其中有一个接口，跟Memory有关的，他原来的的代码是创建后用没有显示释放(这个词第一次听周总说的^_^－－我没有专门学过程序),我用fastMM调试时报一个内存leak错误，直到我加上一个nil fastmm才没有报错，当时加了就了加了，没有研究过为什么，现在TEmbeddedWB最新源码在fastmm面前还是会报这个错误,
我猜这会不会跟delphi对接口管理上或有问题？比如释放的时机，接口生存期有关

[ 本帖最后由 niaoge 于 2007-4-23 12:40 编辑 ]

呵呵，关于接口的使用我曾经总结过一次的，总之就是不要混用对象与接口，尤其是对象作为接口之后不要再强制转为对象使用，不然没有什么太大的问题，delphi倒是会出现多释放的问题，但是不释放的问题倒是不多

显示释放->显式释放，表示明确写明Free或Destroy一个东西。

niaoge 的性能优化思想不错，有空我整理整理，提交到CVS中。

另外，CnWizards可能确实存在内存占用未释放的问题，以前也有用户报告过，但是用内存检查工具一直没查出来。niaoge 提到的现象可以好好测试一下。

显式/隐式释放，前者指在代码中明确写明对资源的释放，隐式指编译器自动生成的资源释放。象局部变量、结构、对象实例等地方，string、动态数组、接口这些有引用计数的资源都会在其父实例释放时自动被释放。比如一个对象有个string成员，释放对象时一般不会有人写条清空字符串的代码来释放字符串吧。或者在函数的局部变量里，也不会有人每次函数退出前都先把字符串清空。这些都是编译器自动会做的工作，因为这些资源都是有引用计数可以进行生存期管理的。

我在D7下使用输入助手总觉得慢慢的（可能是在等IDE编译，CPU占用比较高），可能跟机子有关吧，机子编译也比较慢。

不過的確越來越慢了～～我的機器不差，啟動Delphi第一次用到這個時，好像比較夸張，有時感覺有點想關閉了。。。

周总，刘总，等:
用我自己编译的cnwizards,接口采用显示释放，delphi2007了四个小时也没有死机,bds.exe到现在还只是占用150M的内存，爽死了，
我在网上看了一些范例，像IOTAEditReader一般都作:=nil 处理，结合以前TEmbeddedWB内存报错，我想出了一种理解方法:
1、如果接口是付值而来,这个接口变量会在本过程或函数(视全局或局部变量)执行结束被自动"清理",这个引用的接口对应的被引用者(IDE)的相应实例内是已存在，引用者生成的类似保护 try  finally  end是让被引用者来判断这个结口是不是要释放，至于释放与否那是被引用者(IDE)的事.例如IOTAEditView对应的实例就肯定不能由cnwizards来释放.也释放不了
2、  a.如果接口是由create....而来，这个接口对应的实例在引用者引用之前在被引者(IDE)内是不存在的，是由引用者通知被引用者(IDE)先创建一个实例然后才得到这个接口,也就是说这个结口是由被用引者(IDE)临时创建的,这个实例一定是要占用被引用者(IDE)的内存开销,这种create....可能是在本次程序结束时而不是本过程或函数结束时被引用者生成的类似保护 try  finally  end,虽然最终会被释放的，但是在引用者的生存期内，引用者请求多少次，被引用者就创建多少次实例，这样引起被引用者(IDE)的内存一直往上升,除非引用者调用接口完毕后立即通知被引用者(IDE)这个实例我不用了，你不要在等我了，赶快脱手吧(:=nil)，于是被引用者(IDE)才大胆地把这个实例扔掉。
       b.或者类例于View.Buffer.CreateReader可能被当作全局变理处理，也可能引用者虽然生成了try  finally  end但是根本没有通知到被引用者释放谁,像reader:=View.Buffer.CreateReader,至少能在后面生成的try  finally  end还能指名道姓地点谁。所以像View.Buffer.CreateReader可能只能寄希望于被引用者是否有完备的释放机制了.能否当场释放只能碰巧了,但是被引用者(IDE)肯定不敢乱释放，cnwizards要用，castalia可能也在用,也可能cnwizards用了一会，停下来，再用一会，再停下来，所以被引用者(IDE)不敢释放，只能死挣着直接透支完所有的资源.
3、内存检测工具完全检不出来，那是因为引用者根本没有内存leak,而是引用者导至了被引用者(IDE)的内存泄露，内存检测不会去检被引用者(IDE)
上次传的代码里少了一句，错删了，然后我单独放在后面，不知看到了没有？

[ 本帖最后由 niaoge 于 2007-4-24 09:01 编辑 ]

310的unstable版中已经按照niaoge兄的部分内容优化了一下，下载试一试看看有无效果？

我再补充一句，我刚对给周总留言时无意中想到了toolsAPI里有一句话建义使用共享内存，而我无意中使用了共享内存，所以没有慢下来，别外fastMM也使用了共享内存，
大家可以试试我新编译的dll