使用ref参数是否真的解决了C#代码中的SOH内存分配问题？

问题背景 #

我正在用C#编写渲染程序进行学习。原有代码如下：

V3 _pixel00 = ...; //V3 是一个向量类
V3 _stepU = ...;
V3 _stepV = ...;
double x, y = ...;

...

var pointOnScreen = _pixel00 + _stepU * (x + sS.X) + _stepV * (y + sS.Y);

运行代码时，VS提示最后一行存在「5,000 MB allocated in SOH, 4 issues.」的警告。

于是我编写了如下特殊函数：

public static V3 HorribleFunction(ref V3 a, ref V3 b, ref V3 c, double rateA, double rateB, double rateC)
{
    return new V3(a.X * rateA + b.X * rateB + c.X * rateC,
                  a.Y * rateA + b.Y * rateB + c.Y * rateC,
                  a.Z * rateA + b.Z * rateB + c.Z * rateC);
}

var pointOnScreen = HorribleFunction(ref _pixel00, ref _stepU, ref _stepV, 1, x + sS.X, y + sS.Y);

之后警告消失了。我的问题是：给所有对象使用ref参数是否真的解决了SOH问题？还是我只是骗过了编译器/插件？

更新：以下是运算符的代码：

public static V3 operator +(V3 a, V3 b)
{
    return new (a.X + b.X, a.Y + b.Y, a.Z + b.Z);
}

public static V3 operator *(V3 a, double b)
{
    return new V3(a.X * b,a.Y * b, a.Z * b);
}

问题解析 #

原代码的内存分配问题 #

你的V3是类（引用类型），每次调用+或*运算符都会新建一个V3实例，这些实例都分配在托管堆的SOH（小对象堆）上。原表达式的执行流程会产生4个临时V3对象：

1. _stepU * (x + sS.X) → 创建第1个V3
2. _pixel00 + 上述结果 → 创建第2个V3
3. _stepV * (y + sS.Y) → 创建第3个V3
4. 上述两个结果相加 → 创建第4个V3
   如果这段代码在渲染循环中执行（比如遍历每个像素），多次累积后就会产生大量SOH分配，触发VS的警告。

你的优化为什么有效 #

HorribleFunction并没有依赖ref参数解决问题，核心是消除了中间临时对象的创建：

• 函数直接计算最终V3的三个分量值，只在最后new V3一次，每次调用仅分配1个对象，比原代码减少了3/4的堆分配量，从根源上降低了SOH的内存占用，所以警告确实会消失，这不是骗过工具，是真的解决了问题。

ref参数的实际作用 #

这里的ref参数作用有限：因为V3是引用类型，即使不用ref，传递的也是对象引用（拷贝引用的开销极小）。用ref只是传递引用的别名，避免了引用本身的拷贝，但这不是优化的核心——有没有ref，只要你把多次新建对象的操作合并成一次，就能解决SOH分配问题。

额外优化建议 #

如果想进一步优化，可以把V3改成值类型（struct）：值类型默认分配在栈上（除非被装箱），这样即使有中间临时对象，也不会占用SOH的堆内存，内存分配开销会更低，更适合渲染场景的高频计算。

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