自打使用.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表头找到托管程序的入口地址，并将控制跳转到这里，于是托管程序开始运行。

不过，上述过程在最新的操作系统上不同，因为这些新的操作系统认得托管程序的标志（也就是说知道根据PE文件中的标志去判断是否是托管程序），因此在加载时就会直接调用_CorExeMain，JMP指令直接被跳过的。

刚才说了托管程序在启动时的一些特殊处理：系统在进入入口函数前会首先调用MSCorEE.dll中的代码来启动CLR并做一些初始工作，然后再进入入口函数。但还有个问题没提到：那就是刚才我们有说到托管程序的编译结果是IL代码，这个IL代码是在运行时被CLR实时编译的。那么，这个实时编译的过程又是怎样的呢？

实际上，IL中的方法并不是每次被调用时都会被重新编译一次，而是就像我们平时采用的“LazyLoad”一样，他只有在第一次被调用的时候才会被编译。即时编译器保存有一个映射表。当调用一个方法时，即时编