Why going through all the trouble inventing a new compilation technology such as the .NET Native?
To make the explanation short, if you have a hundred times more powerful processor that is small enough to fit inside the mobile device or any devices, then we are wasting our time on the invention of the new compilation technology. Since the processor inside the mobile devices like the phone or tablet are much weaker than the desktop computer, and you already know the problem of the slow startup time of Windows application due to the use of dynamic compilation where it means it compiles on-demand. So let's assume the small device's processor can run the same app, it will take a very long time to do things on the mobile devices, which is unrealistic. So to minimize the work that the weak processor needs to do, ahead-of-time compiled or static compiled files are packaged along with minimal sets of CLR needed to run on the processor. But if it is compiled ahead of time, how about those dynamic .NET features such as reflection or getting the correct types only at runtime? There are two things make the static compilation possible. One is that in the Visual Studio, there is a .rd.xml file that contains runtime directives configuration file that can tell the .NET Native tool chain to make your application reflectable at runtime. Another thing is the ILC.exe inside the tool chain has the heuristics built-in that predicts what are the things you need to reflect on and what types you want to keep until runtime, and rd.xml files are served as hints for ILC.exe in which that the developers gave.
To make the explanation short, if you have a hundred times more powerful processor that is small enough to fit inside the mobile device or any devices, then we are wasting our time on the invention of the new compilation technology. Since the processor inside the mobile devices like the phone or tablet are much weaker than the desktop computer, and you already know the problem of the slow startup time of Windows application due to the use of dynamic compilation where it means it compiles on-demand. So let's assume the small device's processor can run the same app, it will take a very long time to do things on the mobile devices, which is unrealistic. So to minimize the work that the weak processor needs to do, ahead-of-time compiled or static compiled files are packaged along with minimal sets of CLR needed to run on the processor. But if it is compiled ahead of time, how about those dynamic .NET features such as reflection or getting the correct types only at runtime? There are two things make the static compilation possible. One is that in the Visual Studio, there is a .rd.xml file that contains runtime directives configuration file that can tell the .NET Native tool chain to make your application reflectable at runtime. Another thing is the ILC.exe inside the tool chain has the heuristics built-in that predicts what are the things you need to reflect on and what types you want to keep until runtime, and rd.xml files are served as hints for ILC.exe in which that the developers gave.
In the process of .NET Native tool chain, the ILC.exe scans the entire stack of the program code and devises a plan to optimize the code at first. If the program has included the 3rd party software, it will try to merge it, and follow by a tree-shaking process where unnecessary codes are removed, and then transforms into pre-compiled codes with necessary information made the code reflectable at the end. It is further compiled into MDIL (Machine Dependent Intermediate Language) by a C++ optimizer. Finally, the binder, the last chain tool, converted MDIL into two machine code files: App.dll and App.exe. The reason to have two files are because of there are two states in a mobile device: initial activation and background task. Each file takes care of different entry point of the application.
In summary, the .NET Native tool chain made the entire build process possible where it processed the logic and complexity ahead of time before it reached to the device's processor. In the end, applications start faster and smooth even on the weaker processor.
In summary, the .NET Native tool chain made the entire build process possible where it processed the logic and complexity ahead of time before it reached to the device's processor. In the end, applications start faster and smooth even on the weaker processor.
RSS Feed
