int[,] looks like the natural choice and performs like the wrong one. Digging into IL and JIT output to show what actually happens when you access single-dimensional, multidimensional and jagged arrays — and why the rectangular one loses.
Every array access in .NET pays for a bounds check — unless you convince the compiler it can skip it. I read the JIT'ed x64 assembly and benchmark tricks that make plain array access 18-34% faster.
Interface, base class, virtual, override, dynamic, reflection or expression trees — .NET gives you many ways to call a method, and their costs differ wildly. Full benchmark with numbers for each.
sizeof() compiles to a constant; Marshal.SizeOf() measures the marshaled struct at runtime. What each one really returns, what it costs, and when to use which — with IL to prove it.
What does a method that just calls another method actually cost? Using the == operator vs IEquatable.Equals as the guinea pig, I benchmark wrapper calls across compilers, JITs and runtimes — and read the disassembly to see why.
Unity's Vector2/3/4 and Quaternion lack IEquatable and have a poor GetHashCode, which quietly murders performance the moment you put them in lists or dictionaries. Measurements, explanation, and the fix I reported to Unity.
Game loops check timers constantly, so how cheap is reading time? Environment.TickCount: 7ms for a million reads. DateTime.Now.Ticks: 1392ms. The numbers, and when each is the right choice.
How well does Dictionary<int,int> actually perform? I measured speed and memory with random data and random access on real hardware — with numbers, graphs and a few surprises about what hides behind O(1).