LeetCode两数之和问题中C#两种数组返回方式的性能差异原因探究

这是个挺有意思的细节观察！我来帮你拆解一下这两种写法背后可能的性能差异原因：

1. JIT编译器的逃逸分析与优化策略差异 #

首先，C#的数组是引用类型，默认在堆上分配内存，但JIT编译器会做逃逸分析来判断对象的生命周期——如果一个对象不会“逃逸”出当前方法或代码块，JIT可能会做一些特殊优化（比如栈分配，不过数组的栈分配有特定条件）。

• 对于先声明局部变量再返回的写法：int[] returnArr = new int[2] { i, o }; return returnArr;，JIT更容易识别出这个数组的唯一用途就是作为返回值，它的生命周期很明确，不会在其他地方被引用。这种清晰的结构可能让JIT生成更高效的机器码，比如直接把数组的引用放到合适的寄存器里，减少不必要的内存访问。
• 而直接在return语句中创建数组的写法：return new int[2] {i, o};，JIT在分析时可能需要额外判断这个临时数组的逃逸范围，或者生成的IL指令序列在执行时多了一步临时引用的处理，导致微小的开销被LeetCode的大量测试用例放大。

2. IL代码与执行栈的细微区别 #

我们可以对比两种写法生成的IL代码（简化版）：

• 直接return的IL大致是：

  newarr [mscorlib]System.Int32
  ldc.i4.0
  ldloc.1
  stelem.i4
  ldc.i4.1
  ldloc.2
  stelem.i4
  ret
  

• 先声明变量的IL大致是：

  newarr [mscorlib]System.Int32
  stloc.3
  ldloc.3
  ldc.i4.0
  ldloc.1
  stelem.i4
  ldloc.3
  ldc.i4.1
  ldloc.2
  stelem.i4
  ldloc.3
  ret
  

看起来后者多了“存到局部变量再取出”的步骤，但JIT对局部变量的寄存器优化可能更成熟，反而让这部分代码的执行效率更高——局部变量的引用更容易被缓存到CPU寄存器里，减少堆内存的访问次数。

3. 测试环境的随机性影响 #

最后要提醒的是：LeetCode的计时结果存在一定的波动，服务器的当前负载、其他测试任务的干扰都可能影响单次运行的耗时。你可以多跑几次这两段代码，可能会发现差异有时候会缩小甚至反转。

附测试代码 #

耗时275ms的写法

public class Solution {
    public int[] TwoSum(int[] nums, int target) {
        for (int i = 0; i < nums.Length; i++) {
            for (int o = i + 1; o < nums.Length; o++) {
                if (nums[i] + nums[o] == target) {
                    return new int[2] {i, o};
                }
            }
        }
        return new int[0];
    }
}

耗时181ms的写法

public class Solution {
    public int[] TwoSum(int[] nums, int target) {
        for (int i = 0; i < nums.Length; i++) {
            for (int o = i + 1; o < nums.Length; o++) {
                if (nums[i] + nums[o] == target) {
                    int[] returnArr = new int[2] { i, o };
                    return returnArr;
                }
            }
        }
        return new int[0];
    }
}

内容的提问来源于stack exchange，提问作者johnny bumball