In our last article we have seen a very simple C# program. In respect to this C# program we will see how .NET architecture is going to play a role.
Once we have a program ready. We can compile it with following command.

csc HelloWorld.cs

If no compilation errors are there, it will create a HelloWorld.exe.

To run this program, we can directly type HelloWorld and it will execute the file. Now in relation to CLR what happens internally and how this file is executed is the topic of today’s discussion.

When this HelloWorld.exe is created, this is not a final executable for a specific operating system. This executable is generated in MSIL (Microsoft Intermediate Language) and this is not a regular exe. MSIL is a CPU-independent intermediate language created by Microsoft. CPU will not be able to execute this file without CLR(Common Language Runtime).

So what executable we have created is a PE(Portable Executable). A PE file containing MSIL can run on any CPU platform as long as the operating system running on that CPU platform hosts the .NET Common Language Runtime Engine.

Common Language Runtime Engine
This common language runtime engine first compiles the MSIL instructions into native CPU instructions. These instructions are specific to that CPU. This gives rise to many questions like whether this conversion for all MSIL files should be done at load time? The major advantage of doing this is speed. Once the complete code is compiled to machine code, it will execute much faster. But this will increase startup time and there will be lots of code, which will be used very rarely. So there is a chance that complete conversion might waste lots of time and memory.

Let us take an example of a library management system. There might be various functions namely – issuing a book, adding new books in the master etc.. Now we know frequency of book addition is much less than the frequency of issuing a book. By compiling all code at start up we might have many cases where those functions were not called during the instance of execution.

JIT Compilers
So the conclusion is that it will be more effective to compile the MSIL instructions when the function gets called.
When a method is called, the stub code directs program execution to the component of the common language runtime engine that is responsible for compiling the method's MSIL into native code. Since the MSIL is being compiled just-in-time (JIT), this component of the runtime is frequently referred to as a JIT compiler or JITter. Once the JIT compiler has compiled the MSIL, the method's stub is replaced with the address of the compiled code. Whenever this method is called in the future, the native code will just execute and the JIT compiler will not have to be involved in the process. As you can imagine, this boosts performance considerably.
There is one more good facility offered by Microsoft, which can be used to further improve performance. Prejit.exe. It can compile entire MSIL code to native code and save the result on disk. Next time when a MSIL code gets called it is loaded from disk and the application starts up much faster.

The figure below will explain the compliling of a C# prorgam in detail.

The author, Ms. Vaishali is Director Fands Infotrainers and can be reached at vaishali@fandsindia.com