The C# JIT compiler will inline methods with specific characteristics. Eric Gunnerson has an interesting (but ancient) take on why C# has no "force inline" attribute. His basic argument is that in the majority of cases, the JIT compiler does a much better job than the developer on making inline decisions. But if you're using version 4.5 (or later) of the .NET Framework, you now have the AggressiveInlining attribute flag (compiler hint).whittenizer wrote:Also, removing alot of function calls, and simply putting the code inline, helped alot too as C# doesnt have inline functions.
What hot spots does the performance profiling show?
This is exactly what I've found in my engine Amaia. The JIT compiler creates array elements on the heap even if they're value types. I believe this is related to a rule about object lifetimes. This hasn't proved to be a big issue for me as most of my arrays survive for the complete program lifetime anyway. They're allocated and populated once at program start-up and de-allocated at program close-down.Marco wrote:One of the critical areas is memory management because SF relies heavily on stack allocations, while in .Net fundamental stuff like the arrays have to be allocated on the heap: this kills performance.
I think Richard is absolutely correct. When converting to a language with a very different paradigm, a straight conversion is unlikely to give you equal performance. It's better to be idiomatic in your use of C#, and also you need to be aggressive in using performance and memory profilers to remove significant speed bumps.Richard wrote:From my experiance with Jabba, trying to mimic the C++ code is the wrong way to go about it.