据说FM是使用OpenGL绘制的，可能初始化、释放资源的操作比较耗时，象你的例子，如果这样做可能好很多： ListBox2.Item.BeginUpdate; for i := 1 to 1000 do begin ListBox2.Items.Add('君不见，黄河之水天上来，奔流到海不复回！'); ListBox2.Items.Add('君不见，高堂明镜悲白发，朝如青丝暮成雪！'); end; ListBox2.Item.EndUpdate;
哈哈。。大清早起来看到这个贴，真有意思。我一直用Delphi，不过已经好几年没有写过程序了。我看回贴的大多是Dephi的Fans，不管是本来水平就很好，还是现在准备学，其实，我们可以从程序员的角度去想一想这个问题。1、以前看到有这样的争吵贴，什么“Delphi” VS “VB” VS “VC”之类的，猛扁Delphi，就有大侠(因为别人讲得好，所以我叫他大侠)这样说：“为什么只是扁Delphi，而不是给出有用的建议？其实，Delphi发展得好，对程序员只有好处没有坏处，因为程序员会多一项选择(现在的团队，一般都不是只会一种开发工具的，都是根椐要开发的软件的特点及团队技术积办来选择合适的工具)，而且，开发工具也是有竞争才有进步。”所以，我觉得，这么多的Fans，与其这样吵，还不如专门开一个Delphi的Bug和建议版块，客观的进出Delphi的问题，对Delphi的发展才有好处； 2、我对Delphi的期望，其实并不高。什么支持Win64、什么跨平台，都不是关键，关键在于：稳定。不要在使用IDE的时候弹什么错，不要VCL什么的存在很多的BUG，把文档弄好，把售后服务做好，把开发支持做好。这些方面，Delphi真的没有办法和VS比。但是，VS虽然稳定，但是也有不足。VC开发效率不高，C#又不能用内存,而且我最讨厌.net Framework了。.net？我现在的项目就是用asp.net来弄，我着着头都大。所以，每一种开发工具，都有其优缺点的。再所以，就算是Delphi不支持Win64、不跨平台，但是只要稳定，服务好，我想，还是有很多团队会用它的，因很多项目并不一定要Win64，也并不一定要跨平台。3、我用这么久的Delphi，我觉得Delphi有VS相比，有一个最严重的问题，那就是资源问题。很多人写一些底层点的东西，或是其于MS的什么什么SDK，都会选择VC，为什么？就是因为资源。在VC中，可以直接引用SDK中的Head files，在Delphi中，行吗？你必须要去翻译一次。这就麻烦了。如果Delphi团队能在Delphi中集成那些翻译好的SDK，其实很多底层的东西都可以用Delphi写，而且代码的运行效率也不差，开发效率比VC却要高出很多。可惜，Delphi程序员，要么只有自己翻译，要么只有在网上去找别人翻译好的源代码 - 这还要你人品比较好，能够找到。如果Delphi也能弄一个类假MSDN的资源区，所有的开发资源，都能免费下载到，我想，很多人都会选择Delphi的。因为Delphi适合做的项目，太多太多；4、所以，我想说，如果你喜欢Delphi，就客观的提出建议；如果你希望在开发工具方面多一种选择，就客观的提出建议；如果你有一定要经济实力，尽量买正版的Delphi；
1.三分钟写出一个进程管理器，个把小时写出一个软件管理器，我深信，deeply in my heart! 我就是这种人，呵呵，鄙视我吧，飘柔就是这样自信~！但是新人千万不要误解，此高效，非彼高效！只有VCLer会发出会心的微笑！2.但是在下非常希望知道一件事情，就是.net,java，c++这些能否像delphi那样进行开发呢？她如此犀利，点穴，一针见血，直捣黄龙！什么语言我不关心，我关心的是我懒洋洋的程序人生！3.我爱delphi，i love borland and i respect, admire anders!
我今天测试跟楼主有些差异：如果测试LISTBOX组件，确实不论是批量更新，还是即时更新，FM要比VCL慢很多，但我用TMEMO组件测试，则FM比VCL并不差，甚至还要好很多，代码：CONST N :CARDINAL = 1000; var I:integer; S_TIME,E_TIME:cardinal; begin S_TIME := GetTickCount(); MEMO1.Lines.BeginUpdate ;//注意：在FM中改为：MEMO1.BeginUpdate for I := 1 to N do BEGIN memo1.Lines.Add('科学技术史 ，中国'); END; MEMO1.Lines.EndUpdate ;//注意：在FM中改为：MEMO1.EndUpdate E_TIME := GetTickCount(); FORM1.Caption := INTTOSTR(E_TIME - S_TIME);多次测试，结果显示：如果在批量更新下（也就是启用BeginUpdate），FM跟VCL几乎一样，FM时间为：250多，而VCL的时间为：290多而在即时更新下(（不启用BeginUpdate）)，则FM远比VCL快，FM时间为：1300多，而VCL的时间为：7800多。 所以，不能仅仅从某一个控件上得执行情况来推断整个系统的快慢。
ListBox2.Item.BeginUpdate;
for i := 1 to 1000 do
begin
ListBox2.Items.Add('君不见，黄河之水天上来，奔流到海不复回！');
ListBox2.Items.Add('君不见，高堂明镜悲白发，朝如青丝暮成雪！');
end;
ListBox2.Item.EndUpdate;
d7和xe编译32位的isapi，在64位的iis7.5下总是无法运行。
release是3M
我已经把XE2 Delete了，例子很简单，你们自己做一下就知道了。另外还发现了几个小问题。一是做FIREMONKEY的项目时，你拖动窗体，背景会乱掉，好象是没有通知背景控制重绘，这个问题只在IDE调试时出现。二是简单试了一下MEMO组件，FIREMONKEY的MEMO组件不能正常对中文进行换行，好象只是简单的按空格换行。VCL的MEMO组件则没这个问题。我已经没信心继续吃螃蟹了，你们继续吧。
加上 BeginUpdate() / EndUpdate()的话,时间也是1秒,而且还是在虚拟中装的XE2的.
Add 到非可视的TStringList 时，好象没有必要吧。？
BeginUpdate/EndUpdate可以理解为批量更新，最后一起显示，如果是需要随时刷新怎么办？一般我习惯用个LISTBOX做为LOG窗口，显示一下程序运行状态。不能即时更新，就没什么用了。而且从TMEMO的问题看来，会不会其它的文字控件对于中文的支持也有问题？这些都是最最常用的控件。还有如果真是用OpenGL来绘图的话，我觉得问题也多多，除了专业的显卡，家用显卡对于OpenGL支持都不是太好。还不如封装好DX9，可以做为游戏客户端开发工具。
这不叫试用要什么，难道要花个几万RMB买个，用上几个月才能要试用？我觉的这是一个技术论坛，你可以指正我提出的问题，如象前面兄弟说的BeginUpdate的问题。喷人要带点技术含量的喷。毫无内容的乱喷，还是省省吧。其实严格说来，编译后的文件体积变大也是一个问题，这个肯定会导致启动速度变慢。如果我没有记错的话，同样是空FORM的窗体，DELPHI7是300K左右，而XE2是1.5M左右。如果在编制DLL的项目时会相当成问题。做为一个从DELPHI5发布就开始用DELPHI的老用户，至今还在用DELPHI写点东西。不关心他也就不会第一时间试用了。贴子放在这里，随着时间过去，大家会看到XE2是不是一个划时代的产品。一直找不到好的试用贴子。我希望多一些测试，比如负载能力，用大数量填充一些控件。比如稳定性。长时间的动态创建，关闭一些控件，看看是不是有内存泄漏，真金是不怕火来练的。不要说没有开发资金什么的，你看看SQLite的开发，看看人家的技术文档，编码水准。现在安卓，苹果均把SQLite做为内部支持的数据库。对比DELPHI而言，就象是一个拙壮的小草和腐朽的大树。前景不言而喻。
首先你还是停留在很浅的角度去看XE2，就像很多Delphi程序员只会拖VCL，从来不看VCL代码，天天的工作就是找控件，换控件。人家Delphi的很多控件代码都在那里了，觉得慢你不会加个调试信息？简单的GetTickCount就能算出来是哪个步骤上耗时，哪个函数耗时，为什么耗时。而且你根本不知道FireMonkey的背景，这个软件就是VGSence，BusinessSkin的作者，后来被收编到易宝龙，我估计你也根本没有钱买过这些VCL组件。我的很多用户数量上百万的软件都是用VGSence，BusinessSkin做的，以前都是买的正版的控件，编译出来的程序一般都在3-10MB，因为人家的皮肤控件包含了很多图像元素，现在的宽带用户根本不会在乎你的软件是400K还是10MB。而且如果你结合ASPACK的话，一般Delphi的程序可以压缩60%，安装包很容易控制在10MB以内。Delphi的基础框架是包含了所有运行库在程序内的，bpl的本质就是dll，所以你完全可以利用bpl机制来控制程序群的大小。Firemonkey带来的视觉冲击效果是非常强的，当然前提是你会用这些组件，并且配以美工的素材，可以做出以前任何VCL都很难做到的效果。这个是非常具有卖点的，我用XE2已经在MAC上做了好几个产品了，目前老用户反应的结果都是非常好。所以我最近准备入手一个正版的XE2来为国外客户提供终极产品。Delphi本身就是一个可扩充性非常好的框架例子，所有的模块都是公开的，代码都摆在那里，如果你觉得那里不好，你可以修改他们来达到你的目的，对于我们Delpher，需要的只是稳定的编译器，那就足够了。
首先，我有没有钱买这些VCL组件和我试用XE2，发个贴子，有关系嘛？以前用过VCLSkin,后来用过BusinessSkin,各有所长。最方便是VCLSkin不用改代码。如果是BusinessSkin的话，移植就是大工程了，不过BusinessSkin的好处是换肤比较完整，弹出对话框什么都齐全了，还有自已增加的一些控件。就算BusinessSkin的作者是牛人，就代表Firemonkey一定很牛嘛？从心底上来说，我们也希望Firemonkey很牛，但是做为一个搞技术的，实事求是是重要的。明白了你要用的是Turbo Pascal, 不是Delphi.
果然不出所料，还是停留在VCLskin控件的层面，所以你根本没有接触到Delphi之前版本的不足，也就感受不到新版的优势。
这样的水平早点离开Delphi的好，用TVitualTree三分钟就能写出奇虎的进程管理器来，而且我就是这么写的，竟然说很难，哈哈
人家说的是软件管理器，你就扯到进程管理器。人家什么水平我不知道，好象CSDN搞的什么移动平台开发大会，请人家去演讲的。不过你说三分种写个进程管理器，那估计一天写个360或是QQ啥的也非难事。很久不开贴子，一发贴就碰见大神了。。膜拜下。
软件管理器更简单，用Delphi最简单的Scrollbox，或者TVirtualTree，或者TRichView，或者VGSense的TvgList都是个把小时就能弄出来。
一个空窗口是3M,加10个还是3M，用ASPACK压缩一下，肯定在1M
三分钟升级成个把小时了，才发了几贴效率就下降了20倍。多斗嘴无益，不如你花个把小时搞个软件管理器出来，上传到CSDN，造福广大老百姓，我也学习学习
请装XE2，用FireMonkey的同类控件来测试，这里本来就是对比的VCL和FireMonkey的执行速度。凡事还是亲自动手一试的可靠。
弄了半天你还是不会调试，你在有代码的情况下，也不知道为什么慢，这样只会拖拽控件水平的，早点离开Delphi的好。
这篇文章， 老早我也看到了。
没看多久 就看到他写的
举个简单的例子，要做到 360 软件管理器那样的复杂列表，或是 QQ 那样的界面效果，容易么？
写这种东西， VC和DELPHI 我觉得是同一起跑线。
虽然老久不用DELPHI， 闲来也来看看。
Delphi是你开发的嘛？你要谁离开就离开？有一些人就是一瓶子不满半瓶子晃。随便写个小测试出来，有些人就容不得人家说DELPHI不好,一见就马上跳出来。嘴上总是挂着：你只会拖控件，不会测试想问个仔细为啥不会测试？那你倒是写个详细的测试出来大家看看啊？马上就JJYY不知所云最后就是让你离开DELPHI，更加不知所云张口什么什么三分钟我能做一个，某某不过个把小时写一个。现在学DELPHI都是这些肤浅之辈，真是DELPHI的悲哀。
前面说的橘子，离不离开是人家的事。其实骂也是关心，如果真的没感情，还写什么BLOG？骂DELPHI有人给发5毛？骂也是希望官方能够脚踩实地，做的更好一些。别搞BUG推销。
确实大不是个大问题，但多少是个问题，这是个态度的问题。大了，说明编译器优化部分还没有完善，肯定有一些没用的拉圾给LINK进去了。
对比一下SQLite.刚开发时，作者就定位在500K左右，多少年过去了，现在已经是3.7的版本了。体积还是500多K，增加了多少功能，修复了多少BUG？你可以看一下RELEASE NOTE。我估计人家已经在做ASM级的优化了。为什么安卓，IPOD都用它做内部数据库？无他，品质有保证啊。他的用户手册出来都是厚厚一本书。你能想象嘛？
的确.现在手机流量那么便宜,一个十几M的程序,下载下来也就那么回事.虽然愤怒的小鸟等游戏才几百KB.
应用程序池 -- 设置应用程序池默认设置（或者选择相应的站点池/高级设置）-- 启用 32 位应用程序 = True
其实，真正做项目，体积鲜有少于3M的，但，你会发现，无论你怎样添加第三方组件，delphi的目标程序鲜于大于6M的，原因在于，delphi无论怎样做，它很多扩展的 unit都本源于一些基本的Unit。
虽然，用xe2会比d7体积大个1M，但如果你用它做项目，会发现最终目标程序，只会比用d7多1M多一点点，因为体现不会因为窗口和组件的增加而增加，这种增加不是线性的。
怎样正确测试？怎样修改vcl源码？写个详细的资料让我等初学者学学……
我早就不用delphi多年了，用java都4，5年了。不过这个问题还是想发表下愚见delphi默认静态编译，都编译到一个可执行文件。
vc，.net编译出来的体积小？体积小就不用装vc运行库了，vc运行库下载一个也要3，4M把？
.net运行时更是体积庞大的很。
windows的exe启动不需要调用其他的dll啊，xe2体积是大了点，不过就大这么1，2兆，启动就慢的不行了？？
那你不妨去算算vc启动需要调用多少的dll，算算他们的体积都多少，和delphi比比看
如果因为体积大 再压缩的话 会导致更慢,因为在执行的过程多了一个解压缩过程.XE2没用过不好说,支持 android和IOS是最诱人的地方,有机会试试.
做出的东西又健壮又轻盈的理想是不现实的,只要主流配置跑起来不费力就好了.
2、我对Delphi的期望，其实并不高。什么支持Win64、什么跨平台，都不是关键，关键在于：稳定。不要在使用IDE的时候弹什么错，不要VCL什么的存在很多的BUG，把文档弄好，把售后服务做好，把开发支持做好。这些方面，Delphi真的没有办法和VS比。但是，VS虽然稳定，但是也有不足。VC开发效率不高，C#又不能用内存,而且我最讨厌.net Framework了。.net？我现在的项目就是用asp.net来弄，我着着头都大。所以，每一种开发工具，都有其优缺点的。再所以，就算是Delphi不支持Win64、不跨平台，但是只要稳定，服务好，我想，还是有很多团队会用它的，因很多项目并不一定要Win64，也并不一定要跨平台。3、我用这么久的Delphi，我觉得Delphi有VS相比，有一个最严重的问题，那就是资源问题。很多人写一些底层点的东西，或是其于MS的什么什么SDK，都会选择VC，为什么？就是因为资源。在VC中，可以直接引用SDK中的Head files，在Delphi中，行吗？你必须要去翻译一次。这就麻烦了。如果Delphi团队能在Delphi中集成那些翻译好的SDK，其实很多底层的东西都可以用Delphi写，而且代码的运行效率也不差，开发效率比VC却要高出很多。可惜，Delphi程序员，要么只有自己翻译，要么只有在网上去找别人翻译好的源代码 - 这还要你人品比较好，能够找到。如果Delphi也能弄一个类假MSDN的资源区，所有的开发资源，都能免费下载到，我想，很多人都会选择Delphi的。因为Delphi适合做的项目，太多太多；4、所以，我想说，如果你喜欢Delphi，就客观的提出建议；如果你希望在开发工具方面多一种选择，就客观的提出建议；如果你有一定要经济实力，尽量买正版的Delphi；
用了14年太牛×了，但使用年限长并不代表水平一定高，
因为有些人的技术领域很窄，只是涉及到数据库增删改查和拖拉控件。
研究VCL并无必要，你不会比VCL做得更好，相反擅自乱动会增加bug几率，以前有些人出书描述VCL如何如何纯属浪费时间。对于应用来讲，最快最好的实现业务逻辑才是最重要，界面背后的东西，没有用户管你是怎么弄的，是不是VCL或者MFC。
delphi是有很多不足，欠了太多本来就应该早就出现的东西，这是borland的领导层的脑残导致的，
虽然borland最后也因此而倒闭了。但是害死了不少delphi程序员落伍找不到工作不得不转战其他语言。
很久没上来看了, 最近一直在做项目, 用的还是DELPHI...
别扣我什么误导新手的大帽帽...还有什么资格一类的...评论一个东西要资格嘛? 需要嘛?
我从DELPHI5用起, 做了十几年的DELPHI程序员, 那要说资格的话, 先评评你是不是有资格吧.XE2的问题, 是金子总会发光的. 时间会证明一切. 回头再看, 你就知道什么跨时代,革命性云云是不是言过其实了.
真能扯
调个Add你就知道 delphiXE 不好了？
你真牛13
不得不佩服那些装13的人
1, 稳定, 高效是第一重要. TADODATASET的速度是个大问题, 10W条以上遍历都很慢, 不得不改用原生recordset.
2, 对于各种数据库的支持, 特别是MYSQL, SQLITE这样的.
3, 对于64位, 大内存的支持. 这个将来肯定要用的.
4, 稳定高效的多线程, 网络并发处理控制, 最好支持完成端口的.
5, 还有软件分级, 免费的学习版, 低价的个人版, 以及高端的商用企业版本.
N :CARDINAL = 1000;
var
I:integer;
S_TIME,E_TIME:cardinal;
begin S_TIME := GetTickCount(); MEMO1.Lines.BeginUpdate ;//注意：在FM中改为：MEMO1.BeginUpdate
for I := 1 to N do
BEGIN
memo1.Lines.Add('科学技术史 ，中国');
END;
MEMO1.Lines.EndUpdate ;//注意：在FM中改为：MEMO1.EndUpdate E_TIME := GetTickCount(); FORM1.Caption := INTTOSTR(E_TIME - S_TIME);多次测试，结果显示：如果在批量更新下（也就是启用BeginUpdate），FM跟VCL几乎一样，FM时间为：250多，而VCL的时间为：290多而在即时更新下(（不启用BeginUpdate）)，则FM远比VCL快，FM时间为：1300多，而VCL的时间为：7800多。
所以，不能仅仅从某一个控件上得执行情况来推断整个系统的快慢。
这次代码移植最主要就是String的不同！
计算Dll在CB6下编译2.78M，在XE2下编译4.28M，增大54%
打印Dll在CB6下编译3.33M，在XE2下编译4.83M，增大45%应用程序计算速度在同一台机器和同样数据下测试，原CB6下的程序需要9秒，经Xe2下的程序需要5秒左右！
你用VCL转换到D2D模式，再和FMX比较性能，OK？
就好像DOS的字符界面和windows GUI界面比较性能，基准不同，比较结果都不同。
多学习吧兄弟。