为什么 .net 比 java快？

Question

我想这里面有以下几个原因：1——
先有JAVA后有.NET，这样，.NET在设计上肯定会充分的考虑JAVA在运行上的性能的问题，进一步优化了。2——
.NET虽然也是跨平台的，但目前只是在WIN32下，因此，顾虑的东西相对JAVA要少3——
.NET是MS开发的，在MS的WINDOWS下，JAVA如何也没有办法来跟.NET这个嫡系子孙来比拼实力的4——
JAVA诞生的时候，WINDOWS还只是3.0这个16位版本

Answer 1

1. MS的编译器和Runtime性能本来就很强，当初VJ的性能就是最棒的
2. 语言问题，.NET支持静态成员，Java不支持，这意味着.NET程序远不如Java那样需要随时随地的到堆上创建对象
3. .NET支持值类型的概念，Java没有，而class总是比struct慢
4. FCL内部使用大量的Interop和P/Invoke实现，实际上很多情况只是原有原生程序的包装，性能上肯定快过“什么都用Java实现”的程序
5. ...

Answer 2

拜托，java 的 vm也已经更新了好几代了！我想知道确作的原因而不是猜想！

Answer 3

To Sunmast(速马, Reloading...)  ：觉得 4 可能是主要原因吧！

Answer 4

我不敢说.net在哪里快都比java，但在windows上kenDing是.net快 ^_^

Answer 5

2-4都是主要原因
关于第一条，可以看看李维的《Borland传奇》，当时MS的VJ确实是最强的，我只是说MS在这方面的实力，不是说现在的情况

Answer 6

2. 语言问题，.NET支持静态成员，Java不支持，这意味着.NET程序远不如Java那样需要随时随地的到堆上创建对象java 不支持静态成员？？3. .NET支持值类型的概念，Java没有，而class总是比struct慢能不能说一下class和 struct的内部实现有什么不同，从而导致运行效率的差别？谢了！

Answer 7

嗯...第二条怪我当初没仔细看书哈，支持的（我对Java了解的太少了）关于class和struct：大部分情况下，class在堆上创建，struct在线程堆栈上创建，堆上的对象需要GC这样的东西维护，而线程堆栈上的则线程推出后自动清理
struct不能被继承，这样使用struct内的函数时不需要查找vtable
...

Answer 8

JAVA的虚拟机模式在设计之初就没有太多地考虑效率问题，更多地考虑！

Answer 9

不同吧,.net 程序是经过JIT把IL编译成内部机器码再执行,而JAVA只是解释执行

Answer 10

C# Professional中讲到了。
MSIL在CLR上运行时，是一个JIT编译运行过程。所谓JIT编译就是，当IL assembly运行到原先没有运行过的模块时，JIT编译器就将其编译成本机代码，即二进制代码，并将其在IL中的起始地址修改为编译后的二进制模块的起始地址；没有运行到的部分，仍然还是IL代码。对运行过的部分，已经是本机二进制代码了。这样，当程序第一次运行时，会比较慢，因为正在进行JIT编译，以后便是运行本机二进制文件了，理论上，其速度与其他编译型应用相当。而JAVA则始终是JVM解释执行，这是其与生俱来的：java是解释型语言。不过，以前听说过也有可以将class文件编译成本机代码的机制或技术，但后来没怎么关注过，不知道怎么样了。这是一个普遍适用的规则：编译型程序一般要快于解释型程序。

Answer 11

net的编译只是宣传,其实本质上和java一样,都是生成了一种中间代码再执行中间代码.

Answer 12

如果说 JIT 是完全可以将解释性代码变为二进制代码！那么 4 这个论点何以成立？？都是二进制吗，对原生程序的包装对速度有什么影响？ 4. FCL内部使用大量的Interop和P/Invoke实现，实际上很多情况只是原有原生程序的包装，性能上肯定快过“什么都用Java实现”的程序

Answer 13

一份java jit 技术的介绍 。 就我的印象，java vm 应该挺早就支持 JIT了。http://www.usenix.org/publications/library/proceedings/jvm01/JVM_wips/S17.pdf

Answer 14

上面的解释都错！因为.NET 是编译执行的，真正的机器码运行

Answer 15

to  test7979(test7979)see : http://www.21tx.com/school/dotnet/csharp/37WYKIJNZZOU1NJCHS.shtml

Answer 16

see ： http://www.microsoft.com/china/msdn/archives/technic/faq/0509a.asp
"Java VM（虚拟机）与JIT（Just-In-Time 编译器）之间有什么区别?"  一段，1.1 的java vm都已经支持 JIT了！

Answer 17

回复人： cidli() ( ) 信誉：100  2004-09-06 11:32:00  得分: 0  
 
 
   拜托，java 的 vm也已经更新了好几代了！我想知道确作的原因而不是猜想！
  
 
建议你去问 M$ 和 Sun，.NET 和 Java 不是在座的各位写的吧？在座的哪位敢保证自己了解“确作的原因”而不是“猜想”呢？

Answer 18

回复人： test7979(test7979) ( ) 信誉：100  2004-09-06 15:15:00  得分: 0  
 
 
      上面的解释都错！   因为.NET 是编译执行的，真正的机器码运行
  
 
说话不要太绝对，特别是在不知道自己的想法是否正确的时候。“.NET 是编译执行的，真正的机器码运行”，敢问一句：你真的了解 .NET 吗？（我本人来说是真的不太了解 .NET，指教了！）

Answer 19

同意test7979(test7979) ( ) 信誉：100  2004-09-06 15:15:00  得分: 0  
 
 
   上面的解释都错！因为.NET 是编译执行的，真正的机器码运行
  
 

Answer 20

微软自己开发的东西，当然比java支持好得多

Answer 21

最根本的原因是java要靠jvm解释执行,速度当然要慢一些
而.net执行的时候会被进一步编译成本地代码
多一级代理东西就贵一些,呵呵

Answer 22

其实有时候写程序，一个小小的算法的改变都可以让程序加快很多，执行的快，肯定在底层有许多我们看不到的精心设计的算法与优化，要是他不快给他一百个快的理由也没用，快也不需要理由，一样的实现方法有技术实力做的好就会快很多的解释语言都会在解释以前进行一次或多次的编译过程 我想.NET所谓生成的机器代码并不一定是真正的机器指令代码 一种宣传与炒作吧  我倒是很希望能在VS.NET中直接生成机器代码  至少别人要反编译出源程序很难现在电脑性能已大幅提升，速度已经不象以前那么重要了，以前一个程序慢会让人无法忍受，而现在程序稳定好用才是最重要的

Answer 23

倒分！EastenChild 给出的是正确答案，为什么分给了sunmast?

Answer 24

我ft
1.好像两星以上专家分就没有意义了吧？
2.EastenChild说的并不对，如果是那样的话，可以想一下：不然为啥MS不在编译器阶段就编译成binary而是IL呢，那样Framework都不需要装就可以跑了，多happy啊，java还折腾个啥

Answer 25

to sunmast因为不同的机器码在不同的机器上是不一样的(比方64位机)所以你预先编译成binary不行。MS 在绝大多数的情况下是正确的，所以如果他不这么做一定是有道理的

Answer 26

这也正是.NET的优势所在,它可以根据当前的机器作出做好的优化

Answer 27

支持： Sunmast(速马, Reloading...) 的1、3、4条。