作者：没有昵称 来源：博客园 酷勤网收集 2008-04-18
摘要
因此可以看出，只要程序所有的代码都被执行过一次了，那么整个程序就都会被编译成CPU指令保存在内存中。在此之后托管程序跟非托管程序的执行效率就基本上没什么区别了——当然，托管程序需要从那个映射表中取函数地址，而非托管程序中方法的地址是已知的。
自打使用.Net以来，他给我的印象就一直是：慢。不过这几天看了一下.Net程序运行时的原理，才明白了我们平时的.Net程序是为什么慢的，也明白了在某些情况下其实.Net程序运行起来也不比非托管程序慢。
要看托管程序慢的原因，就得说说应用程序加载的过程。
应用程序文件的格式是有规律的。不管是托管程序还是非托管程序，可执行文件的内部都包含一个PE文件（包含在exe文件或者dll文件的内部），系统也正是根据PE文件里面的信息来启动这些可执行程序的。系统根据PE文件中的信息，找到入口函数，接着将控制调转到这个函数中，从而启动这个程序。不过托管程序的文件中还有一个CLR表头文件以及其他CLR需要的信息。（有关PE文件的信息，请点击这里。个人认为要真正理解托管程序为啥慢，下功夫了解PE文件及其作用还是很重要的）
首先看看非托管程序。非托管程序的可执行文件都是二进制文件，是直接被编译成CPU指令的。在非托管程序的可执行文件中，编译器在编译的时候已经把对方法的调用直接编译成了CPU指令：因为在编译的时候就知道方法在代码段里的相对地址，也就是偏移量。当系统加载了可执行文件后，我们通过将可执行文件的基地址加上这个偏移量就可以计算出方法在内存中的实际地址。这样只要通过这种方法修改JMP指令，就可以直接运行整个程序。
但托管程序不同。因为托管程序编译的结果是IL中间代码，而这个IL代码是由CLR实时编译的，所以在启动这个程序之前，必须先加载CLR，并由CLR负责处理IL代码中的方法调用。
那么，操作系统是如何知道一个应用程序需要加载CLR的呢？也许有人会说因为托管程序的文件中还有一个CLR头部，看到这个就知道是托管程序。这个说法当然不对。最新的操作系统也许能够认出CLR头部，但2000之前的系统，他们如何会认得出CLR头部？要知道当这些系统出来的时候，还根本没有CLR这个玩意儿呢。
实际上，系统启动一个托管程序，最开始的步骤都是一样的：检查PE文件，然后执行PE文件中.text段（也就是代码段）中的代码。但托管程序在编译时，.text段里面增加了一条JMP _CorExeMain或者JMP _CorDllMain的指令（根据是exe文件还是dll文件不同）。也正是从这里开始，托管程序的加载与非托管程序的加载产生了区别。这时候如果是非托管程序，就已经进入到入口函数中去了；但托管程序此时却跳转到了另一个函数中。那么这个函数是哪里的呢？这个函数在一个叫做MSCorEE.dll的动态链接库文件中，当安装了.net框架时就会被复制在系统目录下。系统会根据托管程序PE文件中的信息找到这个DLL，然后通过MSCorEE.dll的PE文件信息找到这个_CorExeMain函数的入口地址，然后修改刚才的JMP指令要跳转的地址，从而将控制跳转到了_CorExeMain这个函数里面去。然后，在这个函数里面，CLR被启动了，并做了若干的初始化工作，然后再通过托管程序的CLR表头找到托管程序的入口地址，并将控制跳转到这里，于是托管程序开始运行。
#4楼 2008-04-17 08:27 young5335 [未注册用户]
看和谁比较了，和汇编，C，C++比，当然慢了；和java比就不一定了。
我觉得最好是核心算法用C或C++保证效率，其他的用C#，扬长避短，效果最好
要看托管程序慢的原因，就得说说应用程序加载的过程。
应用程序文件的格式是有规律的。不管是托管程序还是非托管程序，可执行文件的内部都包含一个PE文件（包含在exe文件或者dll文件的内部），系统也正是根据PE文件里面的信息来启动这些可执行程序的。系统根据PE文件中的信息，找到入口函数，接着将控制调转到这个函数中，从而启动这个程序。不过托管程序的文件中还有一个CLR表头文件以及其他CLR需要的信息。（有关PE文件的信息，请点击这里。个人认为要真正理解托管程序为啥慢，下功夫了解PE文件及其作用还是很重要的）
首先看看非托管程序。非托管程序的可执行文件都是二进制文件，是直接被编译成CPU指令的。在非托管程序的可执行文件中，编译器在编译的时候已经把对方法的调用直接编译成了CPU指令：因为在编译的时候就知道方法在代码段里的相对地址，也就是偏移量。当系统加载了可执行文件后，我们通过将可执行文件的基地址加上这个偏移量就可以计算出方法在内存中的实际地址。这样只要通过这种方法修改JMP指令，就可以直接运行整个程序。
但托管程序不同。因为托管程序编译的结果是IL中间代码，而这个IL代码是由CLR实时编译的，所以在启动这个程序之前，必须先加载CLR，并由CLR负责处理IL代码中的方法调用。
那么，操作系统是如何知道一个应用程序需要加载CLR的呢？也许有人会说因为托管程序的文件中还有一个CLR头部，看到这个就知道是托管程序。这个说法当然不对。最新的操作系统也许能够认出CLR头部，但2000之前的系统，他们如何会认得出CLR头部？要知道当这些系统出来的时候，还根本没有CLR这个玩意儿呢。
实际上，系统启动一个托管程序，最开始的步骤都是一样的：检查PE文件，然后执行PE文件中.text段（也就是代码段）中的代码。但托管程序在编译时，.text段里面增加了一条JMP _CorExeMain或者JMP _CorDllMain的指令（根据是exe文件还是dll文件不同）。也正是从这里开始，托管程序的加载与非托管程序的加载产生了区别。这时候如果是非托管程序，就已经进入到入口函数中去了；但托管程序此时却跳转到了另一个函数中。那么这个函数是哪里的呢？这个函数在一个叫做MSCorEE.dll的动态链接库文件中，当安装了.net框架时就会被复制在系统目录下。系统会根据托管程序PE文件中的信息找到这个DLL，然后通过MSCorEE.dll的PE文件信息找到这个_CorExeMain函数的入口地址，然后修改刚才的JMP指令要跳转的地址，从而将控制跳转到了_CorExeMain这个函数里面去。然后，在这个函数里面，CLR被启动了，并做了若干的初始化工作，然后再通过托管程序的CLR表头找到托管程序的入口地址，并将控制跳转到这里，于是托管程序开始运行。
不过，上述过程在最新的操作系统上不同，因为这些新的操作系统认得托管程序的标志（也就是说知道根据PE文件中的标志去判断是否是托管程序），因此在加载时就会直接调用_CorExeMain，JMP指令直接被跳过的。
刚才说了托管程序在启动时的一些特殊处理：系统在进入入口函数前会首先调用MSCorEE.dll中的代码来启动CLR并做一些初始工作，然后再进入入口函数。但还有个问题没提到：那就是刚才我们有说到托管程序的编译结果是IL代码，这个IL代码是在运行时被CLR实时编译的。那么，这个实时编译的过程又是怎样的呢？
实际上，IL中的方法并不是每次被调用时都会被重新编译一次，而是就像我们平时采用的“LazyLoad”一样，他只有在第一次被调用的时候才会被编译。即时编译器保存有一个映射表。当调用一个方法时，即时编译器如果发现在这个映射表中没有标记这个方法，就会将这个方法的IL代码编译成CPU指令，然后分配在一个内存空间上，然后在这个映射表中记录下这个方法名和方法入口对应的内存地址，然后通过JMP指令跳转到函数中去。当下次再产生对这个方法的调用时，即时编译器因为已经知道了这个方法对应的内存地址，因此就会直接通过JMP指令跳转，而不会再次编译这段代码。
因此可以看出，只要程序所有的代码都被执行过一次了，那么整个程序就都会被编译成CPU指令保存在内存中。在此之后托管程序跟非托管程序的执行效率就基本上没什么区别了——当然，托管程序需要从那个映射表中取函数地址，而非托管程序中方法的地址是已知的。
因此，理论上在某些情况下（比如win service、iis等长期循环执行的程序），托管程序的性能并不会比非托管程序的性能差多少。而且，非托管程序因为要考虑兼容性必须兼容标准指令，而非托管程序因为是运行时编译的，非常清楚操作系统环境，因此可以做针对性的优化。
不过，因为即时编译的结果是保存在内存中的，因此对于那些会频繁启动的程序来讲，其启动过程是会比较慢的——因为每次启动都需要加载CLR并做一次即时编译。
至此，在了解到了托管程序与非托管程序在加载、执行时的区别，我们就可以更加清楚怎样才能充分利用非托管程序的优点、避免其缺点，从而发挥他的最大价值、避免使用时走入误区。
评论
#4楼 2008-04-17 08:27 young5335 [未注册用户]
用NGEN.EXE生成后的速度是不是能快些？WINFORM程序，特别是使用了一些界面控件后，速度慢的让人无法忍受。
NGEN生成的机器码跟WIN32程序相比，速度快还是慢呢？
NGEN生成的机器码跟WIN32程序相比，速度快还是慢呢？
#6楼 2008-04-17 08:30 Da Vinci
原理比较容易理解 但是要清楚在某些情况下.NET程序不一定比其他的非托管的慢 因为CLR会优化一部分代码的运行期过程 这比Java要快多了 甚至有些情况执行速度和非托管的C++差不多
#8楼 2008-04-17 08:32 Da Vinci
@young5335
情况不同 速度也不同 一般来说NGEN的机器码不如JIT的速度 因为优化不如JIT
情况不同 速度也不同 一般来说NGEN的机器码不如JIT的速度 因为优化不如JIT
#9楼 2008-04-17 08:38 lbq1221119
不错 呵呵
系统如何启动托管app,可以参考sscli团队里面的一篇的详细介绍.
系统如何启动托管app,可以参考sscli团队里面的一篇的详细介绍.
#10楼 2008-04-17 08:40 lbq1221119
也就是如果不使用ngen在第一次运行的时候需要便已成为native code.但是这个时候是做了很多的编译器优化,然后把结果存起来,以后经常使用的时候就快多了,一点也不比非托管的慢
#11楼 2008-04-17 08:42 lbq1221119
@Da Vinci
ngen只是针对一套比较通用的cpu指令进行编译的,为了考虑通用性.
jit有很对正对当前的特定平台的编译优化动作.
ngen只是针对一套比较通用的cpu指令进行编译的,为了考虑通用性.
jit有很对正对当前的特定平台的编译优化动作.
#13楼 2008-04-17 08:49 Da Vinci
可以看看jeffer的那本书 很详细的讲了
#14楼 2008-04-17 08:58 gussing
这个不是MSDN中的.net概论那一章嘛。
大家学习.net的时候，难道连概论都不看的？
大家学习.net的时候，难道连概论都不看的？
#18楼 [楼主] 2008-04-17 09:26 没有昵称
@Justin
哈哈，偶技穷了呵。这东东专业术语蛮多的，我还真不知道咋弄个通俗点的东西描述呵。
哈哈，偶技穷了呵。这东东专业术语蛮多的，我还真不知道咋弄个通俗点的东西描述呵。
#21楼 2008-04-17 09:50 簡簡⿺單單..
那么楼主你有没有.Net的针对性优化方案? 譬如: 托管程序预编译等..
#22楼 2008-04-17 09:55 oweb [未注册用户]
确实比别的都慢吗？
#25楼 2008-04-17 11:00 jipp.cn [未注册用户]
.Net程序一点多不慢，
#26楼 2008-04-17 11:09 风海迷沙
比起ASP来，ASP.NET已经无比快了。
#27楼 2008-04-17 11:13 成长的强强
确实在很多情况下和其它语言的程序比起来都要慢些，，
#28楼 2008-04-17 11:17 jipp.cn [未注册用户]
刚才忘了说明一点，运行快不快，决定因素在写程序的人，而不是工具，
#29楼 2008-04-17 11:27 PerfectDesign
说实话，如果你刻意追求速度，你可以不用面向对象的语言啊
开发速度提高是为的响应需求的变化，紧切市场的多变
如果你C开发一年出来了，早就被淘汰掉了，还要干嘛？
.net就是为的现在市场的需求应运而生的吧，能够满足绝大部分市场就成功了。
没必要为了比如每秒多少万并发量的网站来责怪.net的速度
开发速度提高是为的响应需求的变化，紧切市场的多变
如果你C开发一年出来了，早就被淘汰掉了，还要干嘛？
.net就是为的现在市场的需求应运而生的吧，能够满足绝大部分市场就成功了。
没必要为了比如每秒多少万并发量的网站来责怪.net的速度
#30楼 2008-04-17 11:28 Rivers Zhao
.NET程序确实比较慢,但现在的机子越来越快,相信会解决的.但不管怎样,肯定比不上原生C/C++程序快
#31楼 [楼主] 2008-04-17 11:29 没有昵称
@PerfectDesign
呵呵。了解这些的原因就是为了知其所以然，然后更好的发挥.net的长处、避免其短处。仅此而已。没有说发现他有点慢就不用。^_^
c有c的快，快在执行速度；.net有.net的快，快在开发效率。
呵呵。了解这些的原因就是为了知其所以然，然后更好的发挥.net的长处、避免其短处。仅此而已。没有说发现他有点慢就不用。^_^
c有c的快，快在执行速度；.net有.net的快，快在开发效率。
#32楼 2008-04-17 12:01 Angel Lucifer
在跟Native语言同等条件下，我个人认为.NET的程序运行速度比较慢。这里不谈算法和设计。
Microsoft宣称其速度跟C++之类的Native语言速度相比，可以达到其运行速度的98%(跟Java比，两个是半斤八两
)。但是个人体验，能达到90%已经算是谢天谢地了。.NET Base Class Library的编码倾向于以安全稳定为原则，而不是性能。
比如针对2维数组的访问，使用指针来访问与使用索引来访问，性能差了10倍以上，整整一个数量级。运行时检测拖了大大的后腿。
通常有GC的语言，都需要大内存和大缓存才能体现其良好的性能。但是大内存又会导致Cache命中率降低，还真难以取舍。
由于多核成为主流，.NET和Native语言的性能差距会逐步缩减。因为此时系统性能瓶颈根本不在这里了。我们可以想象未来多核CPU的核心>=32时又会是一番什么光景？
Microsoft宣称其速度跟C++之类的Native语言速度相比，可以达到其运行速度的98%(跟Java比，两个是半斤八两
)。但是个人体验，能达到90%已经算是谢天谢地了。.NET Base Class Library的编码倾向于以安全稳定为原则，而不是性能。
比如针对2维数组的访问，使用指针来访问与使用索引来访问，性能差了10倍以上，整整一个数量级。运行时检测拖了大大的后腿。
通常有GC的语言，都需要大内存和大缓存才能体现其良好的性能。但是大内存又会导致Cache命中率降低，还真难以取舍。
由于多核成为主流，.NET和Native语言的性能差距会逐步缩减。因为此时系统性能瓶颈根本不在这里了。我们可以想象未来多核CPU的核心>=32时又会是一番什么光景？
#33楼 2008-04-17 12:03 Da Vinci
Java的运行期和编译期都慢 C#编译期慢 执行期不一定慢
#34楼 2008-04-17 12:06 boyxia [未注册用户]
应该和java比比。
#35楼 2008-04-17 12:07 Angel Lucifer
引用--------------------------------------------------
Da Vinci: Java的运行期和编译期都慢 C#编译期慢 执行期不一定慢
--------------------------------------------------------
@Da Vinci
这番话有什么依据没有？
据我所知，这两个都是基于VM的语言，性能上几乎相当，无非就是这里你快点，那里我快点的区别。--
Da Vinci: Java的运行期和编译期都慢 C#编译期慢 执行期不一定慢
--------------------------------------------------------
@Da Vinci
这番话有什么依据没有？
据我所知，这两个都是基于VM的语言，性能上几乎相当，无非就是这里你快点，那里我快点的区别。--
#36楼 2008-04-17 12:26 Da Vinci
@Angel Lucifer
Jvm.dll加载类库方法是class的字节码 CLR的mscrolib.dll在assembly中有个本地的image(GAC中的是另外的), 这样本地的版本加载之后会比较快一些 个人感觉 请指教.
Jvm.dll加载类库方法是class的字节码 CLR的mscrolib.dll在assembly中有个本地的image(GAC中的是另外的), 这样本地的版本加载之后会比较快一些 个人感觉 请指教.
#37楼 [楼主] 2008-04-17 12:36 没有昵称
@Angel Lucifer
是啊，原来的指针指来指去的，给人感觉非常爽。指针这玩意儿在有些人手里会误伤自己，在另外一些人的手里就会威力无比。
.net为了把这个双刃剑变成安全的，耗费了很多性能上的东西来保证安全性。不过现在硬件的发展已经可以弥补这些了。楼上也有很多兄弟说.net不慢，不过在几年前的pc配置上，那叫一个痛苦啊。。。
其实讨论这个问题，也是为了给一部分程序员一个答案：有些人会视.Net为洪水猛兽，提到.net就以慢为理由来抵制。事实上那百分之几的性能差别，在目前的大部分应用中都不是主要矛盾。
是啊，原来的指针指来指去的，给人感觉非常爽。指针这玩意儿在有些人手里会误伤自己，在另外一些人的手里就会威力无比。
.net为了把这个双刃剑变成安全的，耗费了很多性能上的东西来保证安全性。不过现在硬件的发展已经可以弥补这些了。楼上也有很多兄弟说.net不慢，不过在几年前的pc配置上，那叫一个痛苦啊。。。
其实讨论这个问题，也是为了给一部分程序员一个答案：有些人会视.Net为洪水猛兽，提到.net就以慢为理由来抵制。事实上那百分之几的性能差别，在目前的大部分应用中都不是主要矛盾。
#38楼 2008-04-17 12:45 Da Vinci
@没有昵称
同意LZ观点 指针其实也是双刃剑 任何技术运用不好都是
同意LZ观点 指针其实也是双刃剑 任何技术运用不好都是
#39楼 2008-04-17 13:08 BlueMountain
不过，因为即时编译的结果是保存在内存中的，因此对于那些会频繁启动的程序来讲，其启动过程是会比较慢的——因为每次启动都需要加载CLR并做一次即时编译。
----------------------------------------------------------------
lz确定是在内存中么，c:\windows\Assembly\GAC_32
c:\windows\Assembly\NativeImages_v2.0.5XXXX
那些文件夹里面存的是什么啊??
----------------------------------------------------------------
lz确定是在内存中么，c:\windows\Assembly\GAC_32
c:\windows\Assembly\NativeImages_v2.0.5XXXX
那些文件夹里面存的是什么啊??
#40楼 2008-04-17 13:21 Da Vinci
@BlueMountain
文件夹存的是程序集阿 GAC中是共享程序集 Assembly中的本地程序集的一个拷贝 LZ说的是对的 即时编译结果是在内存中 JIT的事情
文件夹存的是程序集阿 GAC中是共享程序集 Assembly中的本地程序集的一个拷贝 LZ说的是对的 即时编译结果是在内存中 JIT的事情
#41楼 2008-04-17 13:22 李战
路过，这里大都玩.NET的
楼主也不说和谁比，这样就有热闹看，高，实在是高！
楼主也不说和谁比，这样就有热闹看，高，实在是高！
#42楼 [楼主] 2008-04-17 13:58 没有昵称
@Da Vinci
帅哥太客气啦～～～java我不熟悉，这个不清楚呵。
偶现在还没来得及接触java。我搞.net之前是搞VC的，一直都没脱离windows平台。其实我的一些底层的知识也是在原来搞VC的时候学到的。^_^
原本打算准备学习一下java的源代码，不过因为要学的东西太多，还没开始呵。。
帅哥太客气啦～～～java我不熟悉，这个不清楚呵。
偶现在还没来得及接触java。我搞.net之前是搞VC的，一直都没脱离windows平台。其实我的一些底层的知识也是在原来搞VC的时候学到的。^_^
原本打算准备学习一下java的源代码，不过因为要学的东西太多，还没开始呵。。
#43楼 [楼主] 2008-04-17 13:59 没有昵称
@李战
和非托管程序比。不管是c、c++、vb、vc等等，他们生成的winapp的编译、加载过程都是一样的。
偶想说的重点是通过比较他们的加载过程和编译过程，了解.net为啥这么慢，而不是比较谁快谁慢的问题呵。^_^
和非托管程序比。不管是c、c++、vb、vc等等，他们生成的winapp的编译、加载过程都是一样的。
偶想说的重点是通过比较他们的加载过程和编译过程，了解.net为啥这么慢，而不是比较谁快谁慢的问题呵。^_^
#44楼 2008-04-17 14:19 路人小刀 [未注册用户]
实际上，IL中的方法并不是每次被调用时都会被重新编译一次
----------------------------------------------------------------
难怪程序第一次运行时的速度，是如此让人恼火！
----------------------------------------------------------------
难怪程序第一次运行时的速度，是如此让人恼火！
#45楼 2008-04-17 14:21 路人小刀 [未注册用户]
托管程序此时却跳转到了另一个函数中。那么这个函数是哪里的呢？
1). 这个函数在一个叫做MSCorEE.dll的动态链接库文件中，当安装了.net框架时就会被复制在系统目录下。
2). 系统会根据托管程序PE文件中的信息找到这个DLL，
3). 然后通过MSCorEE.dll的PE文件信息找到这个_CorExeMain函数的入口地址，
4). 然后修改刚才的JMP指令要跳转的地址，从而将控制跳转到了_CorExeMain这个函数里面去。
5). 然后，在这个函数里面，CLR被启动了，并做了若干的初始化工作，
6). 然后再通过托管程序的CLR表头找到托管程序的入口地址，并将控制跳转到这里，
7). 于是托管程序开始运行
----------------------------------------------------------------
一共有七个步骤，挺有意思的
1). 这个函数在一个叫做MSCorEE.dll的动态链接库文件中，当安装了.net框架时就会被复制在系统目录下。
2). 系统会根据托管程序PE文件中的信息找到这个DLL，
3). 然后通过MSCorEE.dll的PE文件信息找到这个_CorExeMain函数的入口地址，
4). 然后修改刚才的JMP指令要跳转的地址，从而将控制跳转到了_CorExeMain这个函数里面去。
5). 然后，在这个函数里面，CLR被启动了，并做了若干的初始化工作，
6). 然后再通过托管程序的CLR表头找到托管程序的入口地址，并将控制跳转到这里，
7). 于是托管程序开始运行
----------------------------------------------------------------
一共有七个步骤，挺有意思的
#46楼 2008-04-17 14:30 大林 [未注册用户]
.net算好了，以前编译过一JAVA的项目，竟然编译了半小时才完成
#47楼 [楼主] 2008-04-17 14:32 没有昵称
@路人小刀
整理的很清晰哈。^_^
其实这里面的第六步，“将控制跳转到这里”之前，即时编译器需要把入口函数从IL代码编译成CPU指令，然后才能跳转过去。文章里面讲到这个的时候还没提到即时编译，当时就没指出呵。^_^
整理的很清晰哈。^_^
其实这里面的第六步，“将控制跳转到这里”之前，即时编译器需要把入口函数从IL代码编译成CPU指令，然后才能跳转过去。文章里面讲到这个的时候还没提到即时编译，当时就没指出呵。^_^
#48楼 2008-04-17 14:35 justleo [未注册用户]
其实程序慢的做要原因还是程序设计本身
#49楼 2008-04-17 14:45 A.Z! [未注册用户]
--引用--------------------------------------------------
boyxia: 应该和java比比。
--------------------------------------------------------
支持
boyxia: 应该和java比比。
--------------------------------------------------------
支持
#50楼 2008-04-17 15:10 随风逝去（叶进）
知其所以然了，那该怎么变化，从而改进其执行速度呢？
#51楼 [楼主] 2008-04-17 15:22 没有昵称
@随风逝去（叶进）
我觉得，第一，可以让程序少启动，不过这个适用范围不大；另一个就是多用“延迟加载”。
我觉得，第一，可以让程序少启动，不过这个适用范围不大；另一个就是多用“延迟加载”。
#52楼 2008-04-17 15:35 Da Vinci
@随风逝去（叶进）
改进程序执行速度的方法有很多, 算法, 一些设计模式等等. 针对程序本身原理而言也有很多, 引用类型和值类型的设计, 调用, 方法设计等等. 总之看你具体怎么用. 举一些例子就是在尽量构造函数中初始化字段而不是在类型中初始化; 避免装箱; 延迟加载也是; 用is而不是强制转型......很多
改进程序执行速度的方法有很多, 算法, 一些设计模式等等. 针对程序本身原理而言也有很多, 引用类型和值类型的设计, 调用, 方法设计等等. 总之看你具体怎么用. 举一些例子就是在尽量构造函数中初始化字段而不是在类型中初始化; 避免装箱; 延迟加载也是; 用is而不是强制转型......很多
#53楼 2008-04-17 16:40 birdshome
通用的Framework从来不是为性能设计的
#54楼 2008-04-17 17:04 BlueMountain
不过，因为即时编译的结果是保存在内存中的，因此对于那些会频繁启动的程序来讲，其启动过程是会比较慢的——因为每次启动都需要加载CLR并做一次即时编译。
----------------------------------------------------------------
lz确定是在内存中么，c:\windows\Assembly\GAC_32
c:\windows\Assembly\NativeImages_v2.0.5XXXX
那些文件夹里面存的是什么啊??
回复 引用 查看 删除 修改
----------------------------------------------------------------
@BlueMountain
文件夹存的是程序集阿 GAC中是共享程序集 Assembly中的本地程序集的一个拷贝 LZ说的是对的 即时编译结果是在内存中 JIT的事情
回复 引用 查看
下面这个图，我想知道gac里面的是assembly，那么gac_32呢 gac_msil呢 nativeimages_XX呢 感觉它们好像是存的镜像阿 jit编译的结果仅能存在内存里面么？这样子也未免太笨了吧 ngen生成的又是存在什么地方的呢
#55楼 2008-04-17 17:17 Mainz
看和谁比较了，和汇编，C，C++比，当然慢了；和java比就不一定了。
我觉得最好是核心算法用C或C++保证效率，其他的用C#，扬长避短，效果最好
#56楼 2008-04-17 17:23 222 [未注册用户]
.net也只配和java比比了
#57楼 2008-04-17 17:33 Da Vinci
@BlueMountain
GAC_32是JIT编译的针对32bit机器的程序集 如果是64位的话在syswow路径下面也能找到.因为GAC_32是.NET2.0引入的, 它与GAC的区别是GAC下的是.NET1.1的程序集, GAC_32只是.NET2.0的程序集,没有.NET1.1的.
GAC.MSIL里面是一些轻量级的程序集
这些都是32位机器才有,64位就一个GAC_64
ngen.exe和这些没关系,看你编译的参数,如果你是私有程序集,就是你自己指定的路径阿
GAC_32是JIT编译的针对32bit机器的程序集 如果是64位的话在syswow路径下面也能找到.因为GAC_32是.NET2.0引入的, 它与GAC的区别是GAC下的是.NET1.1的程序集, GAC_32只是.NET2.0的程序集,没有.NET1.1的.
GAC.MSIL里面是一些轻量级的程序集
这些都是32位机器才有,64位就一个GAC_64
ngen.exe和这些没关系,看你编译的参数,如果你是私有程序集,就是你自己指定的路径阿
#58楼 2008-04-17 18:05 研究者 [未注册用户]
你应该多看看相关的资料再来说这个事情！！！！！！
#59楼 2008-04-17 18:06 研究者 [未注册用户]
不知道它的工作机制就不要在此发表言论，OK？
#60楼 2008-04-17 18:09 BlueMountain
@Da Vinci
就是说jit编译的结果的确是仅仅在内存中的，多谢！
就是说jit编译的结果的确是仅仅在内存中的，多谢！
#61楼 2008-04-17 19:38 GoGoSonny
VC6第一次启动快，但VS2005 2008下一次启动快！
比C++，有劣势，但也有优势。
对于JAVA，.NET没的说。
对于脚本，复杂的.NET有优势。
比C++，有劣势，但也有优势。
对于JAVA，.NET没的说。
对于脚本，复杂的.NET有优势。
#62楼 2008-04-17 21:36 techmango [未注册用户]
有这么复杂吗？！看了头晕啊
#63楼 [楼主] 2008-04-17 22:20 没有昵称
@研究者
er，，，我确实是仔细的看了两天资料确认了之后才写出来的啊。
不过如果帅哥觉得我说的不对，你可以告诉我错在哪里么？我也好继续学习。
er，，，我确实是仔细的看了两天资料确认了之后才写出来的啊。
不过如果帅哥觉得我说的不对，你可以告诉我错在哪里么？我也好继续学习。
#64楼 [楼主] 2008-04-17 22:51 没有昵称
呵呵，，，好像很多朋友在这里研究起来谁快谁慢的问题了，呵呵，离题了离题了。
不过，既然这个问题这么敏感，那我就顺便贴两个地址，各位可以看一下这位仁兄在遇到问题的时候是怎样处理的。
先看这个：http://www.cnblogs.com/wuchang/archive/2006/12/07/584997.html
再看这个：http://eparg.spaces.live.com/blog/cns!59bfc22c0e7e1a76!2274.entry
这位仁兄的做法很值得我们思考。他在发现问题的时候第一反应是去分析问题找原因，并最终拨开迷云找到了事情的真相。相信也正是这样的探索精神让这位仁兄成为一个大牛的。
不过，既然这个问题这么敏感，那我就顺便贴两个地址，各位可以看一下这位仁兄在遇到问题的时候是怎样处理的。
先看这个：http://www.cnblogs.com/wuchang/archive/2006/12/07/584997.html
再看这个：http://eparg.spaces.live.com/blog/cns!59bfc22c0e7e1a76!2274.entry
这位仁兄的做法很值得我们思考。他在发现问题的时候第一反应是去分析问题找原因，并最终拨开迷云找到了事情的真相。相信也正是这样的探索精神让这位仁兄成为一个大牛的。
#66楼 2008-04-18 10:01 Anytao
补充：MSCorEE.dll中的代码来启动CLR并做一些初始工作，这些初始化主要包括：
1 创建内存；
2 创建线程池；
3 创建应用程序域名。
关于性能，.NET其实已经有很多优化策略，其自动内存管理上有诸多的优化机制，相比原生态的C代码来说在某些方面甚至表现更优。不管怎样，现在是托管环境的时代，我们越发的了解托管环境，也就能更好的控制性能。
1 创建内存；
2 创建线程池；
3 创建应用程序域名。
关于性能，.NET其实已经有很多优化策略，其自动内存管理上有诸多的优化机制，相比原生态的C代码来说在某些方面甚至表现更优。不管怎样，现在是托管环境的时代，我们越发的了解托管环境，也就能更好的控制性能。