Rust顺序搜索在850万数据量时执行时间突增问题排查

问题描述 #

实现顺序搜索算法的测试代码，遍历Vec查找值为100的元素并修改后退出，当数据量达到850万左右时，执行时间突然大幅飙升。测试流程包含预热、多轮运行并导出CSV数据，用Python脚本生成归一化性能图表。

已排除的干扰因素：

• 测量区间内无隐式内存分配/释放
• 系统后台负载干扰
• 绘图脚本错误（Go实现同算法性能呈严格线性）
• 数值溢出问题

切换为jemallocator后，性能突增现象消失，但存在疑问：测试逻辑中无堆操作，默认分配器为何会引发该问题？

核心原因分析 #

虽然测试的执行阶段没有显式堆操作，但Vec的内存本身是由默认分配器在初始化阶段分配的。Rust默认分配器（Linux下为ptmalloc2，Windows下为mallocng）在处理大内存块分配时，可能存在以下导致性能骤降的情况：

1. TLB命中率骤降：当数据量达到850万时，Vec占用的内存刚好跨越了更多的TLB（Translation Lookaside Buffer）页表项。默认分配器的内存分配策略未针对连续大内存块做优化，导致TLB miss率急剧上升，CPU需要频繁查询页表，拖慢执行速度。而jemallocator针对大内存分配的连续性和TLB友好性做了优化，能维持稳定的缓存命中率。
2. 缓存行对齐与内存碎片：默认分配器长期运行后可能存在隐性内存碎片，导致Vec的内存块未对齐到最优缓存行边界，或被其他内存块分割，引发缓存行颠簸。jemallocator的分配算法在内存对齐和碎片管理上更高效，保证了Vec内存的连续性和对齐性，避免了缓存失效问题。
3. 后台线程资源抢占：部分默认分配器会在后台运行内存整理线程，当内存使用达到阈值时，后台线程被唤醒抢占CPU资源，导致测试代码的执行时间被拉长。jemallocator的后台管理逻辑更轻量化，不会在测试过程中产生额外的CPU抢占。

结论 #

即使测试执行阶段没有堆操作，初始化阶段由分配器决定的内存布局、TLB适配性、缓存对齐等因素，依然会对CPU缓存性能产生决定性影响。jemallocator在大内存块的分配优化上比Rust默认分配器更适合这类场景，因此解决了性能突增问题。

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