Rayon线程池交叉使用引发性能开销问题及解决咨询

程序结构如下：

SequentialPart
ThreadPoolParallelized
SequentialPart
ParallelPartInQuestion
SequentialPart

该代码会被连续调用多次。使用Rayon对第二部分做并行化处理，主要有两种实现方式：

方式一：

final_results = (0..num_txns).into_par_iter()
    .filter_map(|idx| {
        if !matches!(ret, None) {
            return None;
        }
        match last_input_output.take_output(idx) {
            ExecutionStatus::Success(t) => Some(t),
            ExecutionStatus::SkipRest(t) => Some(t),
            ExecutionStatus::Abort(err) => None,
        }
    }).collect();

方式二：

let interm_result: Vec<ExtrResult<E>> = (0..num_txns)
    .collect::<Vec<TxnIndex>>()
    .par_chunks(chunk_size)
    .map(|chunk| {
        // 并行处理逻辑
    })
    .collect();

现象：首次运行性能符合预期，能获得明显性能提升，但第二次及之后的迭代中，第一个并行模块（ThreadPoolParallelized）每次都会慢约20%。推测Rayon运行后残留了需要清理的内容，导致性能下降。

补充take_output函数实现：

outputs: Vec<CachePadded<ArcSwapOption<TxnOutput<T, E>>>>, // txn_idx -> output.

pub fn take_output(&self, txn_idx: TxnIndex) -> ExecutionStatus<T, Error<E>> {
    let owning_ptr = self.outputs[txn_idx]
        .swap(None)
        .expect("Output must be recorded after execution");

    if let Ok(output) = Arc::try_unwrap(owning_ptr) {
        output
    } else {
        unreachable!("Output should be uniquely owned after execution");
    }
}

核心原因：同时创建自定义Rayon线程池并通过par_chunks/par_iter等调用全局线程池时，自定义线程池调用后清理全局线程池会产生额外性能开销。

• 统一线程池使用策略：禁止混用自定义线程池和Rayon全局线程池。如果使用了自定义线程池，所有并行逻辑都通过该池执行，比如用ThreadPool::install包裹并行代码，替代直接调用into_par_iter/par_chunks（这些默认绑定全局池）。示例：

  // 全局复用的自定义线程池（初始化一次）
  static THREAD_POOL: Lazy<ThreadPool> = Lazy::new(|| ThreadPool::new(num_cpus::get()).unwrap());
  
  // 并行逻辑通过自定义池执行
  let final_results = THREAD_POOL.install(|| {
      (0..num_txns).into_par_iter()
          .filter_map(|idx| {
              // 原有业务逻辑
          })
          .collect()
  });
  

• 复用线程池实例：不要在每次代码调用时创建新的自定义线程池，而是在程序启动阶段初始化一次，后续迭代重复使用该池，彻底避免线程创建、销毁和池清理的开销。

• 预配置全局线程池：如果必须使用全局线程池，可通过RAYON_NUM_THREADS环境变量或ThreadPoolBuilder预先固定全局池的线程数，避免动态调整带来的性能损耗。

• 验证资源重置逻辑：确保每次迭代后，outputs向量中的ArcSwapOption被正确重置为有效状态，避免残留空值或无效引用导致的额外分支判断、缓存失效，影响后续迭代的执行效率。

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