用D3D重写控件库

响应速度比GDI快很多

考虑使用异步和多线程

最好是测试一下，时间到底消耗在哪里。网络响应？还是UI呈现？还是客户端数据处理？
不然怎么讨论？

如果从经验上讲，最好例子莫过于DataViews之类的数据控件用不好会让你想拿豆腐撞墙。

我在想您的界面复杂到什么程度，会导致界面响应很慢呢？

UI本身不可能有多慢，你的相关操作所需时间是不是很长，用异步了吗，或者至少DoEvents()用了吗？

垃圾，不懂还说.net的问题，vs的也是.net写的，反映速度可想而知呵呵

运行速度不是问题，.net WinForm最不能忍受的是启动速度，有办法提高吗？

DLL全部强签名，GAC,NGEN
不过有代价....

我觉得Winform的启动和运行性能不是问题,问题主要在实时控制上,当然这是IL代码的通病,如果不知道怎么处理启动的,建议参考SharpDevelop,它的启动一般在3S内(XP,赛3,1.7G,256M).我想这个配置大多都可以达到.况且WinForm不可能频繁的Exit和Logon的.
http://www.icsharpcode.net/OpenSource/SD/Default.aspx

我个人认为。NET程序本身就是一个运行在软件里的软件里的软件了。一切都变得比较迟钝，不但UI比较慢，消息的反应也慢。

同感
特别在窗体需要读取数据库数据填充时，第一次打开时那个慢无法接受的，但过后真的很快很快！

学学飞信吧
这个东西太牛了，不过貌似是有MS的技术顾问

应该多用用 多线程

这个问题的确很烦的
有时候就写几句代码，运行下来内存占用比VC++同样代码多太多

界面响应要快的话应该大部分代码都需要异步化，不过.NET本身的控件不支持跨线程调用，要跨线程的话代码写起来很麻烦。

如果不介意，我可以为你测试一下性能瓶颈所在，你只需要给我程序就可以了，不需要源码。

看到你这样说.net，心里很不爽！

.net的WinForm的确不快，特别是控件比较多的时候。只能说是一般应用也够了。

另：觉得1.1的比2.0的快。

　　感谢大家的回复，不是我说.net不好，.net的思想确实很好，开发效率特别的高，我2001年开始就一到作vb/vc+sqlserver/oracle的开发，我们主要作的是医院管理系统，2001年上的系统，机器的配置差不多是piii 800/128M/20G/15CRT,系统是vb开发，现在还用的好好的，可用.net写出的Winform程序的性能，可以说是差到了极点，同样的配置，在界面上加载数据，vb中的listview控件，c#winform也使用listview控件，他们之间的速度压根就不是一个数量级的，也不是一个层次上的。亚历山大同志也说了，.net界面控抽件不支持跨线程调用，就是用各种方法实现后端调用，又能怎样。.net程序启动狂吃内在，拜托，企业要更换新的硬件需要钱呀！！！
　.net在执行时要把中间编译成本机代码，我想这可能是最大的性能问题吧，我也不知道微软是是怎么搞的，他们类库和控件性能怎么那样差。
　不知大家有没有这样的感受，机器的配置越来越高了，应用程序的性能越来越差了，感觉这软件商和硬件商都怎么搞的。

楼主是五笔高手，呵呵，“线程”打成了“纯种”。

@呵呵

请内vs有多少东西是用.net写的？

.net类库中又多少是用.net写的？？

有的时候是有这种感觉的。
在formload中多加几个控件属性的赋值，程序运行起来怎么就象慢慢地画出来的。
先是四周框框，后来中间部分才出来，用了线程或异步后就好一些。

@81
谢谢，修改了笔误

加几个连接？

微软对.NET失去信心？.NET专家激起千层浪
http://www.yesky.com/113/1924613.shtml

托管代码和非托管代码效率的对比。
http://www.cnblogs.com/wuchang/archive/2006/12/07/584997.html

Winform上控件比较多时（只是把控件放到界面上，并不从后台取数据），可以看到这些空间是一个一个的显示出来的。

建议博主和楼上的兄弟们多了解.net的相关知识，不要盲目评论。顺便说一句，后台线程需要调用主线程委托才能访问控件的。

@有容乃大
谢谢提醒，6年来，一直不断的学习中，以后多向你请教。

>>机器的配置差不多是piii 800/128M/20G/15CRT
-------------------------------------------------
这个配置是差了点，我家里有台老机器比这种配置好一点点（内存大一倍，其他忽略），都不太敢跑vs.net 2003。

旧的机器跑.net程序，性能对比比较明显的

winform这个东西很多地方不是完善，性能吧没以前好，但要说开发效率有多高也说不上，很怀念以前的delphi。

路过，如果不做硬件方面的升级，上.net是一个吃力的事情。搂主估计是在项目实施中遇到了巨大的困难才会如此说。piii 800/128M/20G/15CRT这样的配置根本无法使Winform的程序运行的流畅。如果无法说服客户在硬件上的升级，软件上的升级也无从谈起。只能是在原有的基础上修改。
一般.net winform在P42.4G,512M内存的环境下才能很流畅的运行。

总觉得有一些偏差。
如果单从运行性能来讲，.NET的比较对象应该为同是托管环境的JAVA，而不是C或C++之类的。毕竟它的运行离不开托管程序。不过，我去年做了一个读卡扫描程序，基于整体的需要，没有用他们提供的读卡API，而是通过协议用.NET写了一个。最后的实际效果是两者的速度在同一水平。
另外，WinForm的控件是可以任意调用的。但需要使用委托，将后台线程的数据显示到主线程上。

@魏琼东
我2001年开始就一到作vb/vc+sqlserver/oracle的开发，我们主要作的是医院管理系统，2001年上的系统，机器的配置差不多是piii800/128M/20G/15CRT,系统是vb开发，现在还用的好好的
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
你好，我想问一下，当时你们有没有用一些分布式的框架呢？比如COM+等
你们的管理系统有多少客户端数量？

没有啊,我写的win大型程序很稳定,很快阿.建议多看看国外做的好地软件代码,多理解理解别人的思路,不要局限于固定的开发模式.

基础性能vb很差的，UI用到了系统资源，要把握它必须要了解window的基础以及在这之上的.net封装。
每次不要把系统性能的不理想归咎在.net平台上，现自问一下是不是理解透彻了？对性能做出了分析确认是框架代码产生了系统瓶颈，如果是，把结果贴出来，我们一起分析，并把结果提交给m$。

@火星星
我作大量的运用COM技术进行开发，COM+没有使用，软件是在一个局域网内的使用，我们的医院客户一端客户端都在60-120台终端，服务器配置主要使用那些流行的HP NetServer 7000/6000系列，配置，PIII至强700M,标配256M内在，硬盘18.2G,我们都把内在加到了1G-2G,数据库3-8G

@A.Z
客户的感受，才是第一位的，事实是最好的说服务力。

优化代码说白了就是重写代码，绝大多数草率的代码除了在表面看上去比较正常以外在内部的逻辑和处理是非常糟糕的，比如对windows事件机制没有完全掌握前，你可能在代码里看到一堆一堆无故触发的事件。
vb逐步淡出是必然的，让客户满意的前提是对自己的代码满意。

针对特定的客户，特定的项目决定使用何种技术，如果客户不能提供升级必须的硬件条件，技术再先进也是枉然。

.NET 技术本身是没问题的。

@sharelai
你在窗体加载的时候读数据库主要时间都花在I/O上，这个和Winform无关。
@大豆男生
这个的确是Winform设计使然，因为它使用lazy-loading机制创建底层窗口，这样带来的后果是第一次加载边创建边显示。
解决方法也有，强制遍历所有的Controls取出它的Handle，这样可以抵消它的lazy-loading，可能会有所改善。
@wanghualiang
P3 800其实CPU是足够power的，问题在于内存容量不和谐，这种配置下Windows2000刚刚好，跑XP都会慢。.Net最需要的（其实是Windows最需要的）就是内存，现在内存条很便宜啊，你的软件在部署的时候送客户一跟512M的内存好啦 :p

@Jonny Yu
楼上的哥们
70-100台客户端呀，各送一条512M
.....

大家都说说，怎么优化程序吧。、。。

@魏琼东
呵呵，客户端多卖的copy也应该多，最后反正就是每台机器花200块就可以搞定性能，否则就要多花几个人月来研究如何压榨内存（而且效果好不好还不知道）。


优化程序的这个覆盖面太大了，而且其实说到底优化都是在细节上下功夫，
例如在OnPaint的时候注意针对ClipRectangle处理啊，把磁盘和数据访问的操作尽量使用异步调用啊，增删控件注意SuspendLayout之类。对经常用到的数据想办法缓存。

用profiler看看比较慢的操作 我用的是dotTrace，其实VS2005自己也有一个performance analyzer.

大家的Winform程序一般都是实现什么功能的？
一般会有多少窗体，窗体上一般又有多少控件呢？这些控件都是自绘的还是Winform自带的呢？

楼上的说的不错。多向你学习

。。。。无语，有点研究再下结论，.net是效率不如直接编译的代码，但是效率到无法忍受那就是程序员要反思的问题了。没有什么程序可以不注重效率的，虽然.net给程序员在这方面做了很大的解放性的底层工作基础。.net的即时编译在第一次运行时会慢些。另外clr也会占用比native code更多的内存。两者面向不一样，c++的追求就是高效率和功能强大，.net类库更加面向对象，更易于学习（.net更高层，更面向对象，封装了很多底层的东西，类库在可用性上下了很大功夫，所以代码更可读，开发更容易。）界面上的问题基本上都是程序算法，效率，设计的问题。怪罪到.net上我也就没什么可说的了。

^ō^ 其实我觉得应该从IL层面着手, 因为.Net编译会产生很多的垃圾IL指令...

net的效率真是不一般的次.别的不讲,你试试用ado.net的find和ado里的find.比比,非常清楚.