none
强烈要求本机代码人工编译 RRS feed

  • 问题

  • 其实我最希望的并不是.Net运行库的大小,真正做CS开发的装一下运行库也没有什么大问题,如果实在太大,那么学一下飞信,把需要的Dll直接提取出来一起打包就可以了。

    我最希望的就是微软能把即时编译器开放一个调用接口,最好把这个接口做成一个Console程序,把做好的CS程序直接变成本机代码,这样运行速度能够快一点,反正现在硬盘大小已经足够了。

    每次启动程序花好长时间编译,Java都有本机代码编译器,.Net为什么没有?

    把编译的行为放到安装的时候,直接在客户计算机上编译成本机代码,多好?
    2009年7月27日 14:05

答案

  • 说点废话。

    首先,在开发之前,了解一下用户的客户端运行环境是有必要的,如果确定用户的客户端运行环境有限,达不到足够高的水准,那就应该直接放弃使用.NET的想法,而不用研究如何去提升.NET的运行效率到VC++开发的级别。
    以下是我的臆测,并未经过严格效率测试:
    我认为利用生成本机代码所带来的性能提升并不明显,因为我不知道楼主是否比较赞同以下观点:.NET只是针对本地Windows 32 API的一系列包装和加强,为了在绝大多数情况下适用,其封装和花费在安全性方面的努力常常使这种封装看上去有一点点臃肿,换句话说,完成同样的功能,.NET在底层可能利用多条本地代码指令,而直接利用VC++等可能只需要1、2条本地代码指令就完成了,这种状况不会改变,除非Windows底层全部重写(那似乎也不太可能)。所以如果楼主想追求运行效率,或者用户的客户端运行环境实在苛刻,那么利用VC++等可以更方面直接利用Windows API的编程语言开发更好,当然对于商业业务系统的开发效率上就要打折扣了,对开发者的要求也更高。
    所谓鱼与熊掌不可兼得,如果你想提高开发效率,那么就要牺牲一点运行效率,选用.NET等高开发效率的工具,反之,如果你想写出高运行效率的系统,那就要努力学习提高对Windows底层的认识,然后选用VC++之类的语言,而牺牲一些开发效率。当然,我也希望将来有一种语言或者技术,可以达到开发效率与运行效率双最高。



    理解的越多,需要记忆的就越少

    说的太好了,每项技术都有其对应的使用场景。为客户选择对的技术!
    • 已标记为答案 zjh111 2009年7月29日 7:34
    2009年7月28日 16:15

全部回复

  • 您好,您可以使用NGen.exe。
    也有第三方开发了相应的工具,您可以在网上搜索一下。
    2009年7月27日 14:42
  • Ngen.exe 不是本机代码,是不同的东西,Ngen.exe是把Dll等镜象到内存中,与二进制是两码事..
    继续我的强烈要求
    2009年7月27日 16:25
  • Ngen不是把Dll镜像到内存!
    "The NGen.exe tool that ships with the .NET Framework can be used to compile IL Code to native code when an application is installed on a user's machine." --- 摘自《CLR via C#》
    2009年7月27日 16:39
  • 我有100个Dll难道都要Ngen.exe一次吗??如果我要释放Dll呢?
    如果Ngen.exe能解决问题,为什么微软不建议用它呢?为什么大量的程序员用VC++呢?为什么手机开发还是要用EVC呢?/
    感觉Jiyuan是微软的粉丝吧,,,我就不用搜集些Ngen.exe的信息回复你了....实事 求是地对待技术吧..
    2009年7月27日 18:54
  • Ngen.exe好象就是本机代一样,结果呢??
    请看下面

    在表面上 , 这听起来非常好 , 听上去就像如果你得到了托管代码的全部优点 ( 垃圾回收 , 代码验证 , 类型安全 , 等等 ) 而不牺牲托管代码的性能 (JIT 编译 ), 但是实际情况并不总是那么美好 , NGen’d 文件有几个潜在的问题 :

    Ÿ    没有知识产权保护 : 很多人以为可以发布 NGen 文件而不用发布包含原始 IL 代码的文件 , 从而使他们的知识产权更加保密 . 不幸的是 , 这并不可行 , 在运行时刻 , CLR 需要访问程序集的 metadata( 为某些函数 , 例如反射和串行化函数 ), 这需要发布包含 IL metadata 的程序集 . 此外 , 如果由于某种原因 , CLR 不能使用 NGen’d 文件 ( 如下面所描述的 ), 那么 CLR 会回到 JIT 编译 , 对程序集的 IL 代码进行编译 , 因此 IL 代码必须存在 .

    Ÿ    NGen 文件可能会过时 : CLR 载入 NGen’d 文件时 , 它会比较以前编译的代码和当前的执行环境的很多特征 , 如果任何特征不匹配 , NGen’d 文件就不能被使用 , JIT 编译器进程就要使用 . 这是必须被匹配的部分特征列表 .

    n   程序集模块的版本 ID (MVID)

    n   被引用的程序集的版本 ID

    n   处理器类型

    n   CLR 版本

    n   Build 类型 (release, debug, optimized debug, profiling, 等等 )

    所有链接时的安全性要求都必须在运行时刻被满足才能允许载入 .

    注意有可能以升级的方式运行 NGen.exe, 这告诉工具对以前曾经被执行 NGen’d 的所有的程序集上运行 NGen.exe. 当终端用户安装 .NET Framework 的一个新 service pack, 那么 service pack 的安装程序将会在更新模式下自动运行 NGen.exe, 使得 NGen 文件保持和 CLR 的版本一致 .

    Ÿ    较差的载入时性能 ( 重定位 / 绑定 ): 程序集文件是标准的 Windows PE 文件 , 每个文件包含着一个优先使用的基地址 . 很多 Windows 开发者对围绕基地址和重定位的问题很熟悉 , 关于这个主题的更多信息 , 可以参考我的书 programming Applications for Microsoft Windows, 4th Edition ”. JIT 编译代码时 , 不必关心这些问题 , 因为正确的内存地址引用会在运行时计算出来 .

    然而 , NGen’d 的程序集文件的一些内存地址引用是静态计算的 , Windows 加载一个 NGen’d 文件时 , 它检查文件是否被载入到优先的基地址上 , 如果文件没有载入到优先的基地址 , Windows 会重新定位文件 , 修改所有内存地址引用 . 这是极其耗时的 , 因为 Windows 必须载入整个文件 , 并修改文件中的很多字节 . 此外 , 这个页面文件对应的代码不能跨进程边界共享 .

    因此如果你打算 NGen 程序集文件 , 你应该为你的程序集文件选择好的基地址 ( 通过 csc.exe /baseaddress 命令行开关 ). 当你 NGen 一个程序集文件时 , NGen’d 文件将被赋予一个基地址 , 这需要使用一个基于托管程序集基地址的算法 . 不幸的是 , 微软从没有一个良好的指导来帮助开发者如何赋予基地址 . 64 位版本的 Windows , 这还不太会成为问题 , 因为地址空间是很充足的 , 但是对于一个 32 位的地址空间 , 为每一个程序集选择一个好的基地址几乎是不可能的 , 除非你精确地知道什么东西会被载入到进程 , 知道那个程序集的大小不会超过后一个版本 .

    Ÿ    较差的执行时性能 : 当编译代码时 , NGen 对执行环境做出的假设不会比 JIT 编译器的多 , 这会造成 NGen.exe 产生较差的代码 , 例如 , NGen 不能优化一些 CPU 指令 , 对静态字段的访问需要简介的操作 , 因为静态字段实际的地址需要在运行时刻才能知道 . NGen 到处插入代码来调用类的构造函数 , 因为它不知道代码执行的次序 , 不知道类的构造憾事是否已经被调用了 ( 见第 8 , 类的构造函数 ). 一些 NGen’d 应用程序会比 JIT 编译的代码慢大约 5%, 因此 , 如果你打算使用 NGen’d 来提高应用程序的性能 , 你应该对比 NGen’d 和非 NGen’d 版本的应用程序 , 确定 NGen’d 版本在实际执行时并不慢 . 对于一些应用程序 , 减小的工作集大小会提高性能 , 因此 NGen 总体上还是会取胜 .

    因为上面列出的所有问题 , 当考虑使用 NGen.exe , 你应该非常小心 . 对于服务器端的应用程序来说 , NGen.exe 的用处很小甚至没有意义 , 因为只有第一个客户需求经历了性能上的下降 , 后面的客户需求都是高速运行的 . 此外 , 对于大多数服务器应用程序 , 只需要代码的一个实例 , 因此没有工作集方面的利益 .

    对于客户端应用程序 , NGen.exe 可能对于提高启动速度或者减小工作集有帮助 , 如果程序集被多个应用程序同时使用 . 甚至没有多个应用程序使用一个程序集 , NGen 一个程序集也会提高工作集 . 此外 , 如果 NGen.exe 被用于所有的客户端应用程序的程序集 , 那么 CLR 就根本不需要载入 JIT 编译器 , 从而更进一步地降低了工作集 . 当然 , 如果只有一个程序集不是 NGen’d 或者如果一个程序集的 NGen’d 文件不能被使用 , JIT 编译器就会被载入 , 应用程序的工作集将会增加 .

    2009年7月27日 18:59
  • 我有100个Dll难道都要Ngen.exe一次吗??如果我要释放Dll呢?
    如果Ngen.exe能解决问题,为什么微软不建议用它呢?为什么大量的程序员用VC++呢?为什么手机开发还是要用EVC呢?/
    感觉Jiyuan是微软的粉丝吧,,,我就不用搜集些Ngen.exe的信息回复你了....实事 求是地对待技术吧..
    关于Ngen.exe的优缺点,Jeffrey Richter早已在《CLR via C#》里说的很清楚了,您不能拿.Net的优点来攻击,使用了Ngen,自然会出现编译过时等问题。难道在非托管环境中,您不需要编译100个DLL就能运行?JIT不正式解决这些问题的吗?请了解一下COM的发展史,就会体会到为什么会有CLR!
    每一项技术都有其使用的上下文环境!没有万能的技术!我也并没有说Ngen是万能的!又有谁不实事求是???请问问您自己!!!

    我们在这里探讨问题,不是要谈谁是粉丝,说到底我是中国粉丝!!!我希望中国也有一家软件企业能有微软等国外知名软件企业的影响力!
    可是人家走在我们的前面,我们要学,学的是什么?编程的思想!!!
    不可否认我喜欢C#,特别是其优美的语法,当然您也可以不喜欢!
    使用C#开发已有6个年头了,从中我学到的是思想,因为我不聪明所以我花了5年的时间,才使我眼中每的个类都具有生命,他们各司其职!

    .Net最吸引我的地方是其框架思想,从中学到了很多面向对象、面向组件、面向服务的思想,甚至感悟人生!

    和您沟通也有一段时间了,您的问题我也积极的回答,我并没有要求您一定喜欢C#,喜欢.Net。现在可选择的语言有很多,平台亦有很多。何必让自己这么痛苦?!!
    感觉您带着有色眼镜来看.Net。希望有一天您能摘下眼镜,最最重要的是编程的思想,是您自己有所收获!
    个人观点,仅供参考!
    2009年7月28日 2:52
  • 使用何种编程语言是一个个人爱好问题。如果楼主觉得.NET太烂或者不符合自己的要求,那可以选用自己认为喜欢和合适的编程语言。每种编程语言都有自己的优点、缺点、历史价值和适用场景。
    另外,我承认,我是微软的粉丝,但是我从来不攻击Java以及其他的非微软技术,我也并不觉得非微软技术就一定比微软技术差。

    理解的越多,需要记忆的就越少
    2009年7月28日 4:27
    版主
  • 思想,框架固然重要,注意了,我们用C#开发出来的产品是给客户的, 客户说了算
    我希望C#能编译为本机代码,我们就说能不能实现?如何实现? 有没有必要给微软建议.....等等
    说实在的,现在是效率型和理性消费的年代,你不能为了.NET就让宮户把电脑小小升级一下吧...
    .Net编译本机代码为什么在其它论坛要求这么多,还不是为了让客户感到满意嘛.....
    Vista就让客户体会到了什么叫真正的卡....结果失败了....
    Jiyuan 先生能不能就说.NET编译为本机代码的可行问题,以及它存在的难点,缺点...等等好吗?? 我们不说远了,好吗?/呵呵..
    2009年7月28日 4:56
  • 思想,框架固然重要,注意了,我们用C#开发出来的产品是给客户的, 客户说了算
    我希望C#能编译为本机代码,我们就说能不能实现?如何实现? 有没有必要给微软建议.....等等
    说实在的,现在是效率型和理性消费的年代,你不能为了.NET就让宮户把电脑小小升级一下吧...
    .Net编译本机代码为什么在其它论坛要求这么多,还不是为了让客户感到满意嘛.....
    Vista就让客户体会到了什么叫真正的卡....结果失败了....
    Jiyuan 先生能不能就说.NET编译为本机代码的可行问题,以及它存在的难点,缺点...等等好吗?? 我们不说远了,好吗?/呵呵..

    还有客户要求用Java的,这是一个如何沟通的问题,我并不想多谈。
    关于优缺点您找的比我清楚,而且您当初的问题只是问有没有本地编译的工具,并没有问优缺点!同时我也告诉您有第三方工具,您为什么对这句话置之不理呢?
    我想微软会从Vista吸取经验,至少是一次大胆的尝试,对于个人而言是从中看热闹呢,还是从中分析到学习到什么呢?
    我个人从来不嘲笑前人的付出和经验,我相信微软会做的更好。
    把话题扯远的人不是我。

    关于本地编译,您如果能给微软建议,当然好。期待您的结果!
    • 已编辑 Jiyuan 2009年7月28日 16:09
    2009年7月28日 6:02
  • 说点废话。

    首先,在开发之前,了解一下用户的客户端运行环境是有必要的,如果确定用户的客户端运行环境有限,达不到足够高的水准,那就应该直接放弃使用.NET的想法,而不用研究如何去提升.NET的运行效率到VC++开发的级别。
    以下是我的臆测,并未经过严格效率测试:
    我认为利用生成本机代码所带来的性能提升并不明显,因为我不知道楼主是否比较赞同以下观点:.NET只是针对本地Windows 32 API的一系列包装和加强,为了在绝大多数情况下适用,其封装和花费在安全性方面的努力常常使这种封装看上去有一点点臃肿,换句话说,完成同样的功能,.NET在底层可能利用多条本地代码指令,而直接利用VC++等可能只需要1、2条本地代码指令就完成了,这种状况不会改变,除非Windows底层全部重写(那似乎也不太可能)。所以如果楼主想追求运行效率,或者用户的客户端运行环境实在苛刻,那么利用VC++等可以更方面直接利用Windows API的编程语言开发更好,当然对于商业业务系统的开发效率上就要打折扣了,对开发者的要求也更高。
    所谓鱼与熊掌不可兼得,如果你想提高开发效率,那么就要牺牲一点运行效率,选用.NET等高开发效率的工具,反之,如果你想写出高运行效率的系统,那就要努力学习提高对Windows底层的认识,然后选用VC++之类的语言,而牺牲一些开发效率。当然,我也希望将来有一种语言或者技术,可以达到开发效率与运行效率双最高。



    理解的越多,需要记忆的就越少
    2009年7月28日 9:39
    版主
  • 说点废话。

    首先,在开发之前,了解一下用户的客户端运行环境是有必要的,如果确定用户的客户端运行环境有限,达不到足够高的水准,那就应该直接放弃使用.NET的想法,而不用研究如何去提升.NET的运行效率到VC++开发的级别。
    以下是我的臆测,并未经过严格效率测试:
    我认为利用生成本机代码所带来的性能提升并不明显,因为我不知道楼主是否比较赞同以下观点:.NET只是针对本地Windows 32 API的一系列包装和加强,为了在绝大多数情况下适用,其封装和花费在安全性方面的努力常常使这种封装看上去有一点点臃肿,换句话说,完成同样的功能,.NET在底层可能利用多条本地代码指令,而直接利用VC++等可能只需要1、2条本地代码指令就完成了,这种状况不会改变,除非Windows底层全部重写(那似乎也不太可能)。所以如果楼主想追求运行效率,或者用户的客户端运行环境实在苛刻,那么利用VC++等可以更方面直接利用Windows API的编程语言开发更好,当然对于商业业务系统的开发效率上就要打折扣了,对开发者的要求也更高。
    所谓鱼与熊掌不可兼得,如果你想提高开发效率,那么就要牺牲一点运行效率,选用.NET等高开发效率的工具,反之,如果你想写出高运行效率的系统,那就要努力学习提高对Windows底层的认识,然后选用VC++之类的语言,而牺牲一些开发效率。当然,我也希望将来有一种语言或者技术,可以达到开发效率与运行效率双最高。



    理解的越多,需要记忆的就越少

    说的太好了,每项技术都有其对应的使用场景。为客户选择对的技术!
    • 已标记为答案 zjh111 2009年7月29日 7:34
    2009年7月28日 16:15