So I decided to build an abstraction layer ontop of this in order to achieve similair ease of use.
I’ve built a serializer/deserializer that deals with my own XML structure for documents (state + metadata) and also an early Linq provider for querying.

This is my second post on .NET performance, in this series of posts I will try to show how .NET code performs compared to pure C++ code.
Today I will show how a C# for loop compares to a Win32 C++ for loop.

First we need some sample code to compare, so here it is:

The C# code:

The Win32 C++ code:

I hope we can agree that the above code is fairly similair, we loop “i” from 0 to 999 and call the function “Foo” while doing so.

I will begin with the disassembly for the C++ code, just so we can see how optimized it is:

What are we seeing here?
The “i” variable have been replaced with a native register (esi) which is set to 1000.
The Foo function have been inlined in the for loop.
The loop guard have been optimized to “esi — ; if esi >0 goto loopbody” since this is more efficient in native code (dec,jne)
So the C++ code is clearly very optimized.

So how does the C# counterpart hold up against the optimized C++ code?[Edit] big thanks to Omer for pointing out how to disassemble the optimized .NET code.

Just like the C++ version, the variable “i” have been replaced with a native register, “esi”
The Foo function call have been inlined (address 6-18), do note that calling console.writeline is not the same as calling cout in win32, so the code will differ.
So the optimized .NET code is pretty much equal to the win32 C++ version.

Today I attended one of Juval Löwy’s sessions on our inhouse conference.

He argued that every object in .NET is a COM object behind the scenes, even Int32.
Fair enough, Int32 is a type and it does have a Guid.
The argument was an attempt to show that .NET is slow and that everything is pushed around as a COM object internally, even the integers…
(This was an up ramp for his “every object should be a WCF service”, to show that performance doesn’t matter, much..)

This is however completely wrong..
.NET have specific IL op codes in order to deal with primitives, and those opcodes will translate to pure machine code.

Here is a C# code snippet:

Here is the same code disassembled into x86

The value hex 7B (dec 123) is moved directly into the memory slot for the local variable.
No COM objects involved, no nothing, just normal machinecode, as long as you treat it as an int that is..
You can not make this faster or better even if you resort to pure ASM.