That is a question that I have been answering for years. The answer is an emphatic “NO” in most cases.
What is true is that .NET make it very easy to write slow code. [tweet]Being more friendly, it is pretty standard for .NET developers being sloppy and uncritical about performance and that, I think, is the main reason why some .NET applications performance sucks.[/tweet]
RavenDB team is doing a great job proving, again and again, that managed code can be so fast as Native Code. Why? Because we pay attention to performance starting from the architecture to the implementation.
When you build your .NET code, the compiler translates it to Intermediate Language and metadata. Then, when you run your code, whenever a method is executed for the first time, the Just in Time Compiler convert it to assembly code. Most of the code optimization happens at this stage (If you want to understand this process, I recommend you to read this post).
The quality of the JITted code is fantastic. Microsoft has improved the JIT, especially quite recently.
In fact, there are advantages in the Managed World:
- Since the code is JITted as it is executed, its location in memory is better than that of native code. The related code will be often closer, commonly in a single memory page or the cache. So we have fewer page faults;
- Different from Native Code, .NET applications are less susceptible to memory fragmentation and. When it happens, the Garbage Collection compacts the heap solving the problem.
- The memory allocation occurs with no contention.
Remember: Garbage Collection in .NET is non-deterministic. But, we can significantly affect how often it runs by controlling the memory allocation patterns, object scope, etc.
Uma resposta
Maybe it would be good to have an example to compare the performance between native (in c, for example) and the same code using .net; despite the fact that I understood the problem is more related to the architecture. (disclaimer: I didn’t see the video yet) I usually see many projects that write pieces of the project natively using the excuse that it is for performance reasons.