C# has value types, which follow the same memory model as in C (i.e. stack-allocated for locals, embedded directly into the outer object as fields). You can request explicit layout mode, whereby you can set an offset for every field manually - if you set them all to zero, you get a C union. Alternatively, you can request automatic layout mode, where the JIT is allowed to reorder the fields in arbitrary ways to optimize memory and/or access, which is something you don't even get in C.
It has raw pointers. Unlike object references, these have the usual C semantics - there's no GC involved there, and you're responsible for keeping the objects alive, so you can have dangling pointers etc. No boundary or null checks, either - it's zero overhead. You can do pointer arithmetic on them, including indexing with []. If you P/Invoke malloc or equivalent, this gives you C-style heap allocated arrays.
It has stackalloc, which is a language operator that's equivalent to the non-standard alloca() function in C - allocate a chunk of memory on the stack, and return a pointer. This immediately gives you stack-allocated arrays as flexible as C99 VLAs.
With generics, if a generic type parameter is a value type, the specialization for that type is separately JIT-compiled and optimized. This can be used in a way very similar to C++ templates, for zero-overhead inlined callbacks and similar shenanigans.
All in all, if you want to write high-perf code in C#, you certainly can. You'll hit the limits of the JIT optimizer soon enough - it can't be as good as a full-fledged AOT C++ compiler, say - but you can certainly shed most of the overhead associated with a managed language.
The binding is a bit funky (lots of `ref` and `gcnew` keywords sprayed here and there) but it works.
As for the rest at least we can hope Java 10 brings them.
You missed a few C# goodies from 7.0 up to 8.0, coming from the experience with Midori.
https://github.com/dotnet/roslyn/blob/master/docs/Language%2...
It does (The JIT that is), but it also often does not. For example a regular for loop does not bounds check anything. The newer x64 JIT ("RyuJIT") is a whole lot smarter than the legacy x86 jit was.
I imagine that once you start producing proper native binaries using whatever backend you want instead of a JIT that has a requirement of being FAST in addition to making code that is FAST, you can get even more optimization done.
Also, bounds check are becoming cheaper and cheaper as memory fetches become (relatively) more expensive with every hardware generation.
C++ code is usually faster than C# code but bounds checking is probably not the biggest culprit. If you use "idiomatic C#" with reference types, most operations have a lot of memory fetch overhead with pointer chasing etc.
It's possible to write pretty efficient C# code, and it can still look pretty nice. You end up using arrays more, structs more, obviously worrying about AoS vs SoA more. You should also look at the new ImmutableArray types that look like List<T> but have effectively no overhead compared to a plain array. After that comes Span<T>, which makes even more exotic things possible.
The optimal thing to do would be to memcpy several KB of data at a time from your heap-based memory, into your stack-allocated memory, do your processing in the optimized inner-loop, then commit the data back to the heap. I had to do this once to increase the throughout of a cluster of image processing servers.
I often scoff at the idea that C# isn't a good choice for performance-intensive tasks.
We've been compiling our large C# games to native code for some years now because iOS only supports signed code. The main problem is you can never JIT; this creates all sorts of limitations with generics, dynamics, expressions and reflection.
Xamarin has become better and better at handling generics but there are still a couple of things they just can't do anything about.
>Memory
Yes, the memory looks bad because it will not get completely collected until needed. The framework code is big, but that's a flat cost. It might take a little more memory for the runtime up keeping, but it is not 10x. However, memory profiling is a breeze compared to native, so it becomes easier to optimize on a large complicated project.
>Performance
If you don't want to bound check there are a lot of solutions, from simple to advanced. Most of the time we end up just iterating the whole array anyway, and in those case, there are no bound checks.
In the rare case where we really need raw power (graphics, path finding, physics, large file access), we use native code and thin wrap it with P/Invokes.
For the rest, we use System.Math. They are not used enough to be a significant bottleneck.
It's coming... https://github.com/dotnet/corert
And it most certainly didn't do anything about the dependencies on the runtime (VM, GC etc).
https://docs.microsoft.com/en-us/dotnet/framework/net-native...
It's not to say that C# will always be 10x memory usage, however, it will always be somewhat higher. Even with a linker, when you run a .NET app, it's not just loading your C# code, but also .NET code that you call into (linker helps keep this slim) and of course the Common Language Runtime C++ code that executes your app and manages its memory.
This is currently being worked on. With the addition of Span<T>, many APIs will soon have a version that does not allocate and instead use a buffer you pass in (which can be managed or unmanaged).
For compilation into a native binary, there is the corert project:
Memory: The memory usage "looks" bad. I suppose maybe GC would kick in when it needs to. It has not been a problem for me, but when you see the code in C++ taking 1MB ram and a C# implementation taking 10MB, well, you have to wonder.
Performance: C# performs bounds checking, which I take it is a significant performance hit. I've not had this matter yet, but I've not converted everything over to .NET.