async函数不使用futures::Stream无堆分配返回Vec的性能分析

• 你当前实现的Vec按值传入、填充后返回的方案，已经消除了函数内部新建Vec带来的堆分配开销：如果调用方复用同一个Vec实例（每次调用前执行clear()清空内容再传入），整个业务生命周期里只需要做一次初始内存分配，后续调用不会产生任何额外堆分配开销，相比函数内部新建Vec返回的写法，在高频调用、单次返回条目数较多的场景下，性能提升非常明显，也能减少内存碎片问题。
• 这个实现本身的额外开销极低：Vec的按值传参、返回走的是move语义，仅复制栈上的三元胖指针（指针、长度、容量），不会拷贝堆上的实际数据，这部分开销几乎可以忽略不计。

这个方案在你的约束下不是绝对最优，需要结合场景选择：

• 如果编译期就能确定单次返回的最大条目数，完全可以做到零堆分配：直接传入栈上固定长度数组的可变引用，或者用栈上存储的固定容量容器（比如ArrayVec）作为入参，连初始的Vec堆分配都能省掉，是性能最好的方案，示例代码如下：

// 已知单次最多返回16条Item的场景，完全基于栈存储，无任何堆分配
async fn read_items(offset: usize, count: usize, tmp: &mut ArrayVec<Item, 16>) -> Result<()> {
    tmp.clear();
    // 填充数据逻辑，注意不要超过ArrayVec的固定容量
    Ok(())
}

• 如果编译期无法确定固定条目上限，你当前的思路已经非常接近最优实践，只需要做一点小调整即可：不需要按值传入再返回Vec，直接传入&mut Vec<Item>可变引用，省掉无意义的所有权流转，API更符合Rust生态的惯例，性能和原写法完全一致，示例代码如下：

async fn read_items(offset: usize, count: usize, tmp: &mut Vec<Item>) -> Result<()> {
    tmp.clear();
    // 可根据count提前reserve足够容量，避免填充过程中触发扩容
    tmp.reserve(count);
    // 填充数据逻辑
    Ok(())
}

调用方使用这个版本的接口时，只需要在第一次调用前用Vec::with_capacity(预期最大条目数)提前分配好足够容量，后续所有调用都只需要清空内容后复用，不会触发任何堆扩容分配，完全满足你避免堆分配的要求。

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