将数据移动到 Rc/Arc 是否总是将其从堆栈复制到堆？

Question

看看下面这个简单的例子：

use std::rc::Rc;

struct MyStruct {
    a: i8,
}

fn main() {
    let mut my_struct = MyStruct { a: 0 };
    my_struct.a = 5;
    let my_struct_rc = Rc::new(my_struct);

    println!("my_struct_rc.a = {}", my_struct_rc.a);
}

Rc的官方文档说：

Rc<T> 类型提供T 类型值的共享所有权， 在堆中分配。

理论上是清楚的。但是，首先my_struct 不会立即包装到Rc 中，其次MyStruct 是一个非常简单的类型。我可以在这里看到 2 个场景。

1. 当my_struct 移动到Rc 时，内存内容实际上是从堆栈复制到堆。
2. 编译器能够解析my_struct 将被移动到Rc，因此它从一开始就把它放在堆上。

如果数字 1 为真，那么可能存在一个隐藏的性能瓶颈，因为在阅读代码时没有明确看到内存被复制（我假设 MyStruct 要复杂得多）。

如果数字 2 为真，我想知道编译器是否总是能够解决此类问题。提供的示例非常简单，但我可以想象my_struct 要复杂得多，并且在移动到Rc 之前会被不同的函数多次变异。

Answer 1

Tl;dr这可能是任何一种情况，但在大多数情况下，您应该以最明显的方式编写代码，让编译器担心它。

根据抽象机的语义，即定义 Rust 行为的计算理论模型，总是有一个副本。事实上，至少有两个：my_struct首先是在main的栈帧中创建的，然后必须被移动到Rc::new的栈帧中。然后Rc::new 必须创建分配并再次将my_struct 从它自己的堆栈帧移动到新分配的内存*。这些动作中的每一个在概念上都是一个副本。

但是，这种分析对于预测代码在实践中的性能并不是特别有用，原因有以下三个：

1. 副本实际上非常便宜。从长远来看，将my_struct 从一个地方移动到另一个地方实际上可能比使用指针引用它要便宜得多。在现代处理器上复制一大块字节很容易优化；不是跟随指向某个任意位置的指针。 （请记住，结构的复杂性 无关紧要，因为所有移动都是按字节复制的；例如，移动任何Vec 只是复制三个usizes，而不管内容如何。）

   如果您没有测量性能并表明过度复制是一个问题，那么您不能假设它没有证据：您可能会不小心悲观而不是优化您的代码。 先测量。

2. 抽象机器的语义不是你真实机器的语义。优化编译器的全部意义在于找出将一个转换为另一个的最佳方法。在合理的假设下，这里的代码非常不太可能在启用优化的情况下生成 2 个副本。但是如何编译器消除一个或两个副本可能取决于其余代码：不仅取决于包含它们的 sn-p，还取决于数据的初始化方式等等。实际机器性能很复杂，通常需要一次分析不止几行。同样，这是优化编译器的重点：它可以进行更全面的分析，比你或我更快。

   即使编译器“在桌面上”留下一个副本，您也不应该在没有证据的情况下假设删除该副本会使事情变得更好，因为它是一个副本。 先测量。

3. 在这种情况下，这可能并不重要。从堆请求新分配可能比从一个地方复制一堆字节到另一个地方更昂贵，因此在忽略（可能的）大瓶颈的情况下摆弄一个快速副本与无副本可能是浪费时间。在分析应用程序或库以查看性能损失最大的地方之前，不要尝试优化事物。 先测量。

另见

关于不小心放入大数据导致堆栈溢出的问题（解决方法通常是使用Vec而不是数组）：

• How to allocate arrays on the heap in Rust 1.0?
• Thread '<main>' has overflowed its stack when allocating a large array using Box

---

* Rc，虽然是标准库的一部分，但是是用纯 Rust 代码编写的，这就是我在这里分析的方式。 Rc 理论上可能会受到普通代码无法使用的保证优化的影响，但这恰好与这种情况无关。

† 至少取决于分配器以及是否必须从操作系统获取新内存，或者是否可以重新使用最近释放的分配。