I've read some of blogs over
the web in which the bloggers complain to the performance of CLR(Common
Language Runtime). some of the arguments those bloggers come up with
against CLR and .NET in general are to some extent fully justified.
Yes, .NET applications are compiled into MSIL(Microsoft Intermediate
Language) at compile time,and at runtime, the compiled MSIL have to be
JIT(Just In Time) compiled into native CPU instructions before getting
executed, although the second compilation process only happens once,
but you still sense the performance hit out of it if you write some
comprehensive and mission critical applications, that's the major
reason why .NET is far less popular in destop application development
than in web application development. I've heard tons of professional
developers even some Microsoft MVPs recommend using unmanaged C++ and
Win32 APIs to develop windows desktop applications, they have two very
good reasons for doing so: First, the .NET framework's BCL(Base Class
Library) and Winforms class library in particular is lacking of some
important functionalities which as a result force developers to
unwillingly use Win32 APIs and unmanaged APIs through P/Invoke and COM
interop; Second, as I have mentioned above that the performance of .NET
desktop applications are not good enough.
I am by no means a winforms
developer, in actuality, I am just an amateur devoloper who has great
interest in computer programming. I have some sort of experience(if I
can call it) with ASP.NET programming, and I think the performance of
ASP.NET is alright decent enough, but I really like to know how to
improve the performance of CLR, because CLR is such a superb runtime
environment, if its performance can be improved a lot, it will become
perfect.
Here are some of my personal thoughts on how to improve the performance of CLR:
- Directly compiling the source code into native CPU instructions at compile time. this capability is alright available through NGen.exe tool that ships with the .NET framework SDK, but this tool only generate a native copy of the MSIL code, which does require additional disk space, sometimes, this overhead is disastrous(imagine you have a .NET application with 100MB of MSIL code).
- Having the future CPU natively support MSIL. I think this probably is the most efficient way to improve the performance of CLR, and I think it is workable, because MSIL is alright standardized, if the CPU manufacturers can have their products natively support the execution of MSIL, they can build their CPUs with two pipelines, the one for the execution of traditional x86 instruction set, and the other for the execution of MSIL, so the existing unmanaged applications won't get affected. MSIL is an object oriented type safe assembly language, and if the future CPU can directly support it, the future applications will get those benefits that are previously associated with .NET framework, such as application robustness, application securities etc.
