Dave strikes again, a basic description of how .NET works.

Dave asks:

i have tried some UI examples in the book, but it was quite slow. when I execute the program, it takes 1.5-2seconds to see the window on the screen, on the other hand plain win32 api creates window before 1st second. doesn't .net generate native win32 binary code? what does it load/do delaying application so long?

What exactly IS .NET? First, .NET is a cross-language application framework - the same types and methods that you access in C++ are accessed in different (sometimes the same) way in C#, VB.NET, ASP.NET, and so on. (This is why, when I talk about a managed C++ feature, I usually say it is exposed in Whidbey C++.) Since the Common Language Specification (CLS) is an ECMA standard, and freely available, expect to see more (including non-Microsoft) language implementations targeting the .NET framework in the near future. (.NET perl, anyone?)

In order for multiple languages to apply to a single framework, an assembler-type language is used, called Microsoft Intermediate Language, or MSIL. All .NET-targeted languages compile their code to MSIL (in C++'s case, a mixture of native code and MSIL). The MSIL is then compiled to native machine code on-the-fly by a JIT (Just-In-Time) compiler. The JIT is basically a VM, similar in concept to the Java VM.

So, why is my sample slow? The performance hit you see (why the program takes a few seconds to load as opposed to miliseconds) is the JIT compiling your code. However, we take this tradeoff for a number of performance benefits the JIT provides. These performance benefits are nearly invisible in small programs - such as examples - and hugely beneficial in large applications. I'm not going to go into them here, because other people have done it better. Stay tuned for a really great link on the perf benefits of the CLR.

i am really into it, but i have a question && suggestion; why you are providing a garbage collector? instead of that, it would be better to track memory leaks with visual studio .net ide, like BoundsChecker was doing with vs6. because garbage collector is using system resources, may be it causes cache misses, too. of course, i have no idea about its implementation, you engineers probably considered such cases.

Do we really want/need a Garbage Collector? This isn't the first time I've heard this - and almost always from C++ users, too. We're such a type-A breed, always wanting to do things ourselves (mostly out of speed considerations). But the short-term losses you might perceive in the overhead of a GC are far outweighed by the benefits you reap. Again, I'm going to provide a link, I promise.

(To be totally clear, it isn't C++'s Garbage Collector. It is the .NET GC, and we're simply leveraging it. All .NET targetted languages are, by default, garbage collected.)

What about low-overhead solutions like BoundsChecker? Well, on the surface, these seem to be good solutions, but they aren't always. First, consider that the GC performs optimizations that non-GC environments (native C++) can't take advantage of. For example, choosing when to destruct/collect an object. In native you have to do it when the stack is being unwound (even if the CPU is at 99% usage) - in the GC world, you could choose to wait for processor lull. Second, solutions that look for memory holes only find the holes you create - you still have to patch them up. With the GC, you can't create memory holes, that worry simply never crosses your mind. (And besides, not to slam the IDE team, but do you really want the IDE - which you pointed out can't seem to manage its own memory leaks - trying to manage yours?)

So, where's that link? There's a great article on MSDN that has an explanation/justification of all the benefits provided by the .NET framework - and the theory behind why managed code isn't slower than native, and why it has the ability to be faster. It has sections on the GC, the JIT, Thread Pooling, Appdomains, and so on and so forth. It even has an Overview of the .NET framework, if my crappy one-paragraph explaination above wasn't sufficient for you.

Anyhow, if you want to know more, I strongly encourage you to check out this article.