首次执行带par_unseq的std::for_each为何耗时是后续10倍？

关于虚表缓存的可能性 #

虚表缓存不是导致10倍耗时差的原因：虚表在程序启动阶段就已加载到内存，首次调用虚函数仅会触发一次虚表指针的访问，这个开销微乎其微，不可能造成量级差距。除非Detector的虚函数内部包含首次调用才触发的懒加载逻辑，但你明确说明代码无静态局部变量，这种情况可以排除。

核心原因分析 #

1. 并行执行框架的初始化开销

std::execution::par_unseq依赖的底层并行框架（如libstdc++的OpenMP、MSVC的Concurrency Runtime）在首次执行并行任务时，会完成线程池创建、线程初始化、调度器启动等重量级操作，这些都是一次性的高开销流程。后续调用时线程池已经就绪，直接复用现有线程，耗时自然大幅降低。

比如OpenMP首次遇到并行区域时，会初始化线程池，这个过程涉及线程创建、系统资源分配，开销远大于后续任务的调度成本。

2. 内存缓存预热

首次执行时，共享std::vector、Detector类的成员数据、并行任务用到的代码段都处于冷缓存状态（可能在磁盘或内存的非高速缓存区），CPU需要将这些数据加载到L1/L2/L3缓存；后续调用时，这些数据和代码已驻留在高速缓存中，缓存命中率大幅提升，这是导致耗时差异的最常见原因。

尤其是当共享vector数据量较大时，首次加载到缓存的开销会非常明显。

3. 互斥锁的底层初始化

虽然你没有静态局部变量，但std::mutex首次执行锁定/解锁操作时，可能会触发内核态同步对象的创建等底层初始化逻辑，不过这个开销通常远小于线程池初始化和缓存预热，一般不会是10倍差距的主因，仅作为辅助因素存在。

验证与优化建议 #

如果要确认具体原因，可以做以下测试：

• 在程序正式业务逻辑启动前，先调用一次空的Detector::Detect（或仅触发并行框架初始化的空任务），提前完成线程池和缓存预热，后续正式调用的耗时会趋于稳定。
• 单独剥离并行逻辑，测试Detector的串行处理流程，看是否仍存在首次耗时高的问题，以此排除并行框架的影响。

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