你们觉得C# 开发出来的winfrom程序运行效率低吗?

你们觉得C# 开发出来的winfrom程序运行效率低吗? 有什么方法可以解决呀???在同样配置的机子
做同样功能的情况下我用VB做编译成exe时,双击打开5秒左右程序就运行好了.而用vs2003 c# 做的生成exe后  , 双击运行这个程序起码要15秒以上才出来!这是为什么呀!!运行C# .net程序时对机子的配置要求高些的吧!这样太不爽了!

解决方案 »

  1.   

    1、你的机器可能有点落后了。我的相关应用打开很快。2、效率可以不必太考虑，从实践上看能用上2年以上的商业软件不太顾及效率，商家顾及的是效果和什么时候能入手这个软件，他们有的是钱帮你垫机器性能；
    3、如果你的需求真的要很高的效率，那还是不要考虑.net，托管代码给人的是开发使用的便捷而不是底层开发的简单。
    调用windowsapi create一个自定义窗口。用.net很麻烦。如果楼主开发中真的遇到了底层要求很高的项目，那薪水也会很高的，初中生都能入门的.net肯定是不能适应开发的了。
      

  2.   

    还好吧
    看看我写的这个软件，数据还是从文件实时读取，蛮快的http://community.csdn.net/Expert/topic/4929/4929270.xml?temp=.4591181
      

  3.   

    一般来说,.NET平台开发的APPLICATION在小程序上体现不出什么优势来
    但是,程序越大,连续运行时间越长,优势就越明显
      

  4.   

    请你阅读一下你的SDK文档吧...........SDK工具里自带有个小家伙可以把你的启动速度提升几十到上千倍...只需要命令行一句命令而已......为什么都懒得敲一下 却怪程序启动慢?15秒,呵呵,起码提升几十一百倍应该没什么问题.
      

  5.   

    而且你说的是启动,不是运行,这是很大区别的..Net 程序在理论上执行(非启动)效率可以高于所有其他编译性语言(包括C++),更不要说半编译性的和解释性的了. 原因在于jit编译器生成的本地码可以充分使用CPU特殊指令.而其他编译器因为编译和运行发生在不同的机器上,加上对机器硬件的保守估计(为了通用)少了这个优势.
      

  6.   

    看下框架吧。因为dotnet编写得是与平台务关得，所以是属于中间代码，不是真正得二进制本机代码，在程序运行时才把中间代码翻译成本地代码来运行得。
      

  7.   

    其实在开发程序的时候,如何快速的开发和程序的效率都可以找到相应的平衡点,不容否认C++运行效率是比.net高,但快速的开发会选择.net,选择.net是不是不用考虑效率了呢?我选择平衡点.
    加载速度慢不表示执行效率低,应该看执行过程中的效率.
      

  8.   

    请你阅读一下你的SDK文档吧...........SDK工具里自带有个小家伙可以把你的启动速度提升几十到上千倍...-----------------
    麻烦告知是什么工具, 谢谢
      

  9.   

    在内存白菜价的年代还这么心疼内存占用率的人不多了,呵呵
    天生是个做C开发的人,何必搞什么.NET呢!
      

  10.   

    靠！
    说到这个话题就郁闷！
    我们老大要创造奇迹，让我们用.net写工控软件，大部分主机的配置都是爷爷级的了（比如什么奔二的，主频一两百兆的机器）。 机器配置太差了，这丫偏要搞，老天啊...神啊！救救我吧！
      

  11.   

    和JAVA竞争的话主要应该在WEB开发吧，Form 应该不是强项，
      

  12.   

    回复人：atls(亮) ( 一级(初级)) 信誉：100  2006-08-05 21:41:00  得分:0
    ? 
    靠！
    说到这个话题就郁闷！
    我们老大要创造奇迹，让我们用.net写工控软件，大部分主机的配置都是爷爷级的了（比如什么奔二的，主频一两百兆的机器）。 机器配置太差了，这丫偏要搞，老天啊...神啊！救救我吧！
    =================================
    这个老大太英明了
    呵呵
      

  13.   

    .Net 程序在理论上执行(非启动)效率可以高于所有其他编译性语言(包括C++),更不要说半编译性的和解释性的了. 原因在于jit编译器生成的本地码可以充分使用CPU特殊指令.而其他编译器因为编译和运行发生在不同的机器上,加上对机器硬件的保守估计(为了通用)少了这个优势.
    --------jit编译器充分使用CPU特殊指令难道就可以抵消运行时编译所带来的性能损失？？这么说还真会让人幻想winform程序能够快过C程序了
      

  14.   

    .net作的winform程序能快过C++？快过C?
    那是不可能的,.net做winform程序根本就没有优势
      

  15.   

    .Net 程序在理论上执行(非启动)效率可以高于所有其他编译性语言(包括C++),更不要说半编译性的和解释性的了. 原因在于jit编译器生成的本地码可以充分使用CPU特殊指令.而其他编译器因为编译和运行发生在不同的机器上,加上对机器硬件的保守估计(为了通用)少了这个优势.
    ====================================================================
    似是而非的欺骗言论。
    这其实是在假定：
    1. JIT编译器从IL代码间接编译来的本机代码比直接从源程序生成的本机代码还优化；
    2. 直接从源程序生成的本机代码没有针对当前处理器进行优化；
    3. JIT编译器的编译不耗时间。
      

  16.   

    两手都要抓，两手都要硬
    我做win程序一般还是选择VC++。
    如果实在懒的话就用C#
      

  17.   

    第一次启动时要先启动.net framework，所以慢，启动起来后就快了。不是启动你的程序慢，而是启动.net framework慢
      

  18.   

    我现在刚开使接触.net 各位大虾能不能给点儿宝贵的建议
      

  19.   

    既然根本不能脱离Windows运行，
    搞什么虚拟机代码根本就是脱裤子放屁。
      

  20.   

    请你阅读一下你的SDK文档吧...........SDK工具里自带有个小家伙可以把你的启动速度提升几十到上千倍...-----------------
    麻烦告知是什么工具, 谢谢
      

  21.   


    我用WinForm+Web service做的远程查询速度还可以，hoho
      

  22.   

    请你阅读一下你的SDK文档吧...........SDK工具里自带有个小家伙可以把你的启动速度提升几十到上千倍...-----------------
    麻烦告知是什么工具, 谢谢
      

  23.   

    应该是Ngen.exe了。用来将托管程序生成本机映象的。
    可参考：http://msdn2.microsoft.com/zh-cn/library/6t9t5wcf.aspx
      

  24.   

    微软不是说了么 .NET出来以后
    很多以前搞EXCEL的 WORD的都开始做程序了
     
    你要它的易用性和扩展性 加上很多似是而非的新功能
    又要效率高 是不可能的习惯了C语言 
    适应.NET需要点时间 不要和C语言比 
    和JAVA比它的效率的确是高le
      

  25.   

    请你阅读一下你的SDK文档吧...........SDK工具里自带有个小家伙可以把你的启动速度提升几十到上千倍...只需要命令行一句命令而已......为什么都懒得敲一下 却怪程序启动慢?--你要是知道就说出来，只需要敲一句命令而已。还要别人拿着SDK从头翻上几天？怎么这么小器啊。
      

  26.   

    用 Ngen.exe 快不了多少
      

  27.   

    那么慢阿，MS，JAVA的GUI也比它快阿
      

  28.   

    那就用 delphi 得了 ...
      

  29.   

    自从用.NET开发了一个WINFORM项目以后就开始怀念C++了
      

  30.   

    我用C#写了一个和串口通讯的程序，很慢，不是程序启动慢，而是发送给下位机指令很慢，目前还不知道为什么，以前用VB写的时候指令发送很快的
      

  31.   

    回复人：atls(亮) ( 一级(初级)) 信誉：100 2006-08-05 21:41:00 得分:0
    ? 
    靠！
    说到这个话题就郁闷！
    我们老大要创造奇迹，让我们用.net写工控软件，大部分主机的配置都是爷爷级的了（比如什么奔二的，主频一两百兆的机器）。 机器配置太差了，这丫偏要搞，老天啊...神啊！救救我吧！
    ++++++++++++++++++++++++++++++++
    这叫老来福！98的老爷爷娶了个18岁的大姑娘，凑合者吧！
      

  32.   

    第二次不那么慢是由于Windows保留了JIT编译后的本机代码，运行的是它。
    但是认为经过JIT编译器二次翻译的“本机代码”比直接由源代码编译而成的本机代码还优化，在普遍意义上，这是不可能的。存在少量的特例，但那说明不了问题，不具有普遍性和代表性。
      

  33.   

    高配置的系统中,DotNet 和纯C++的程序看不出有什么区别,有时性能甚至超过C++(因为C++写的东西,一般来说都有一个适应环境,一但条件非常优越了,反而它自己不知道该如何生活,这点DotNet是优越的,因为它会根据环境去配置内存,但C++就只能是墨守成规了),但在配置相对较低的机器上DotNet的劣势是相当时显的,关于第一次,还是第二次运行的问题,我接触过的程序,全是这样,第二次一定要比第一次快的多的多.
      

  34.   

    但是认为经过JIT编译器二次翻译的“本机代码”比直接由源代码编译而成的本机代码还优化
    -------jit编译器能如何优化，直接由源代码就能做到如何优化，所以说在这一点上只要C编译器开发商愿意，随时可以让jit编译器毫无优势，但为了照顾兼容，编译器开发商往往会采用更老的机器指令，所以jit编译器还是有机可乘，但实际上这样做提升性能的空间非常小，与运行时编译IL代码所带来的性能损失相比，可以说微不足道，也就是说dotnet的优势可以让它的性能提高1,但劣势却能让它的性能损失10甚至更多。
      

  35.   

    最终也是编译为机器代码，不过涉及framwork,运行时需先编译，占用内存肯定比C大了。
      不过，跟C确实没什么好比的，也没什么比的必要.C快那是绝对的，汇编更快！！
      

  36.   

    这点可能与人的编程习惯有一定的关系,实际上在我所处理环境(如客户的硬件配置等等),我感觉大部分客户所配置的内存是相当低的(与CPU同比来说,因为企业用户更认同品牌机,品牌机一般是这种理念),在用C或C++做程序时,一般来说,都是比较关心内存的申请和释放的,而且心中只有一个观点就是目标机的内存可能要比想象的低,而且从资源中,也会有一种非常宝贵的感觉,实际上最终把精力全放在了内存管理上,而且由于代码最终变得相当复杂,实际上正常处理业务的代码没多少,大部分代码全管理内存了，当然后来才出来的引用计数等机制可以简化这些，但最终对于一些大对象，出于保险，还是自己去管理了，而且就算你不删，运行环境检测到引用为0时也会删,不过.Net不一样,实际上Net处理方式,最终的想法只是在应用结束时去释放内存,实际上我发现.Net产生内存泄露的地方相当多（比如一对互引用的委托对象同时变成迷途指针时，你是没办法去Dispose它的，而且它只有在应用退出时才会调用终结器）,所以编写服务器程序,我从不用.Net,虽然简单了不是一点半点。但官方只是不直接指明这点，而是用他的内存管理方式去搪塞了，所以在内存管理方面，.Net应该在高配置的机器上是更有弹性的，如果C/C++中，一个大的对象，可以你会选择在暂时不需要时，让它去“析构”，而在.Net中，你不需要去管，你也管不了，而不断的去“析构”重建一个大对象，代价是相当高的，有时.Net的管理方式可能会带来更快的效果，牺牲的代价也是相同大的
      

  37.   

    我们目前还不受这个影响，用VC++?那繁琐的报表、密密麻麻的数据组件，足够把开发周期再延长一年了，而且客户还特别注意程序的“面子”，同样工作量VC做的界面相比，有点惨
      

  38.   

    开发小应用，还是喜欢Delphi接分，呵呵！
      

  39.   

    我用C#写了一个和串口通讯的程序，很慢，不是程序启动慢，而是发送给下位机指令很慢，目前还不知道为什么，以前用VB写的时候指令发送很快的你可以用C＃调用一些组件来发串口指令啊，这样速度感觉没有什么影响啊
      

  40.   

    小项目用.net蛮好，追求高性能，控制底层，用C++
      

  41.   

    恩 .NET主攻主流业务C++ 用在低层 都有用都要学 不学.NET没有潮流 不学C++技术上永远不能上层次