第2部分高级软件工程主题开发模式与平台资料.ppt

Matrici We already know that an assembly does NOT contain native binary code, but instead MSIL code. Obviously before the MSIL code can be executed it must be converted into native binary instructions. Converted? Does this mean interpreted? NO! The MSIL code is compiled and not thrown away. This means that next time the code is requested it is already in the form of machine instructions and thus this mechanism in the log run is far more efficient than an interpreter for example. The compilation is carried out by a JIT Just In Time compiler. Does the compiler compile all of the code in one go? The answer to this question is NO. If this approach was taken there would be a long delay during the applications initialisation, and realistically not all the code within the module will be required in one go. Instead, when the code is loaded a ‘stub’ is connected to each method. When a method is called via the stub the compiler generates the binary native code. This mechanism goes a long way to describing why the compiler is called a ‘JIT’ compiler. Microsoft intends to ship two JIT compilers, the normal compiler and the so called ‘Economy’ compiler. The normal JIT compiler will be installed on to most platforms. The normal JIT compiler is an optimised compiler which takes time out to examine the MSIL code in order to generate the most efficient binary code. On platforms such as Windows CE machine where processing power is more limited it is thought that the somewhat less intelligent Economy compiler will be installed. The Economy compiler simply subsitutes the MSIL code with the equivilant binary code. Obviously the Economy compiler will actually compile code much more quickly but the resultant code will not be optimised and will therefore execute more slowly. The benefits for to this system is obviously portability. So, what are the cons? Performance. Obviously managed code is never going to outstrip native binary code! Or is it that simple? A cou