Maximizing .NET Performance

Foreword by .NET Remoting guru Ingo Rammer BACK IN 1999, the ACM published a study1 that presented a comparison of 40 independent implementations of a computationally intensive problem, created by different programmers in either Java-the then-current managed runtime environment-or C/C++. It concluded with the finding that interpersonal differences between the developers 'are much larger than the average difference between Java and C/C++' and that 'performance ratios of a factor of 30 or more are not uncommon between the median programs from the upper half versus the lower half' This should teach you something: If you are not a guru-level C++ programmer, then the chance is quite high that a managed code implementation performs as well as the average C++ solution-especially given the fact that most .NET languages simply allow you fewer possibilities to introduce subtle memory related or performance-related issues. And keep in mind that this study was conducted several years ago, and that Just-In-Time Compilation (JIT) as well as memory management and garbage collection (GC) technologies have been improved in the meantime! This however doesn't mean that you can't create horribly slow, memory-eating applications with .NET. That's why you should be really concerned about the other part of the study's conclusion, namely that 'interpersonal differences . . . are much larger' In essence, this means that you have to know about how to optimize your applications so that they run with the expected performance in a managed environment. Even though .NET frees you from a lot of tasks that in C++ would have been your responsibility as a developer, these tasks still exist; these 'little puppets' have only cleared the main stage and now live in some little corner behind the scenes. If you want your application to run in the top performance range, you will still need to find the right strings to pull to move these hidden figures