. Net why are you so slow

Document directory

• Comment

Since I started using. Net, he has always been impressed by the slow speed. But I have read it over the past few days. net program running principle, to understand our usual. net program is slow, but also understand in some cases.. Net programs are not slower than unmanaged programs.

The process of loading an application depends on the reason why the hosting program is slow.

The application file format is regular. Whether it is a hosted or unmanaged program, the executable file contains a PE file (including the exe file or dll file ), the system starts these executable programs based on the information in the PE file. Based on the information in the PE file, the system finds the entry function and transfers the control to this function to start the program. However, the host program file also contains a CLR header file and other information required by CLR. (For PE file information, click here. I personally think that it is important to understand PE files and their roles to really understand why hosting programs are slow)

First look at the unmanaged program. The executable files of unmanaged programs are binary files and are directly compiled into CPU commands. In the executable file of an unmanaged program, the compiler has directly compiled the call to the method into a CPU command during compilation: because the relative address of the method in the code segment is known during compilation, that is, the offset. After the system loads the executable file, we can calculate the actual address of the method in the memory by adding the base address of the executable file with this offset. In this way, you can directly run the entire program by modifying the JMP command in this way.

But the hosting program is different. Because the result of compiling a managed program is the intermediate IL code, which is compiled by the CLR in real time, you must load the CLR before starting the program, the CLR is responsible for processing method calls in the IL code.

So how does the operating system know that an application needs to load CLR? Someone may say that the hosted program file contains a CLR header, and it is known that it is a hosted program. This is certainly not true. The latest operating system may recognize the CLR header, but how can they recognize the CLR header in systems earlier than 2000? You know, when these systems come out, there is no CLR.

In fact, when the system starts a hosting program, the initial steps are the same: Check the PE file, and then execute the code in the. text section (that is, the code segment) in the PE file. However, when the hosting program is compiled, a jmp _ CorExeMain or JMP _ CorDllMain command is added in the. text section (depending on whether the file is an exe or a dll file ). From this point on, the loading of managed programs is different from that of non-managed programs. At this time, if the program is not managed, it has already entered the entry function; but the managed program now jumps to another function. So where is this function? This function is stored in a dynamic link library file named MSCorEE. dll. When the. net Framework is installed, it is copied to the system directory. The system will find the DLL based on the information in the PE file of the hosting program, and then use MSCorEE. find the entry address of the _ CorExeMain function in the PE file information of the dll, modify the address of the JMP command to jump to, and redirect the control to the _ CorExeMain function. Then, in this function, CLR is started and Initialization is performed. Then, the entry address of the managed program is found through the CLR header of the managed program, and jump to the control here, so the hosting program starts to run.

However, the above process varies with the latest operating systems, because these new operating systems recognize the Host Program Logo (that is, they know whether it is a hosted program based on the logo in the PE file ), therefore, the _ CorExeMain command is called directly during loading, and the JMP command is skipped directly.

As mentioned above, some special processes of the hosting program during startup: the system will first call MSCorEE before entering the entry function. dll code to start CLR and do some initial work, and then enter the entry function. But there is still a problem not mentioned: we mentioned just now that the compiling result of the managed program is the IL code, which is compiled by CLR in real time at runtime. So what is the real-time compilation process?

In fact, methods in IL are not re-compiled every time they are called, but just like the "LazyLoad" we usually use, it is compiled only when it is called for the first time. The instant compiler stores a ing table. When a method is called, if the real-time compiler finds that this method is not marked in this ing table, it will compile the IL code of this method into a CPU instruction and allocate it to a memory space, in the ing table, record the memory address corresponding to the method name and method entry, and use the JMP command to jump to the function. When this method is called again next time, the real-time compiler jumps directly through the JMP command because it knows the memory address of the method, instead of compiling the code again.

It can be seen that as long as all the code of the program has been executed once, the entire program will be compiled into CPU commands and stored in the memory. After that, the execution efficiency of the hosting program and the non-hosting program is basically no difference-of course, the hosting program needs to retrieve the function address from the ing table, the method address in a non-hosted program is known.

Therefore, theoretically, in some cases (such as long-lived programs such as win service and iis), the performance of managed programs is not much inferior to that of unmanaged programs. In addition, non-hosted programs must be compatible with standard commands because of compatibility considerations, while non-hosted programs are compiled at runtime, so they are very clear about the operating system environment and can be optimized accordingly.

However, because the results of real-time compilation are stored in the memory, for those programs that will be started frequently, the startup process is slow-because the CLR needs to be loaded and compiled immediately at each startup.

At this point, we have learned the differences between hosting and non-hosting programs during loading and execution, so we can better understand how to make full use of the advantages of unmanaged programs and avoid their disadvantages, so as to maximize his value and avoid mistakes in use.

Comment # is the speed of young5335 [unregistered users] generated with NGEN. EXE faster? WINFORM programs, especially when some interface controls are used, are slow and unbearable.
Compared with WIN32 programs, does NGEN generate a machine code faster or slower? # The Principles of Da Vinci are easy to understand on the 6th floor, but it should be clear in some cases. NET programs are not necessarily slower than other unmanaged programs because CLR will optimize the runtime process of some code, which is much faster than Java. In some cases, the execution speed is almost the same as that of unmanaged C ++.