为何模块化C++ deque滑动窗口最大值代码比非模块化版本更高效？

这是个很有意思的问题——很多人会想当然地认为把代码合并到main里减少函数调用会更快，但你的实际测试结果正好相反。从Python解释器的运行机制、CPU缓存优化等学术角度来看，主要有以下几个核心原因：

1. 局部变量 vs 全局变量的访问效率差异 #

在Python中，局部变量的访问速度远快于全局变量。模块化版本里，printKMax函数的所有变量（比如数组切片、窗口索引、临时最大值）都是局部变量，解释器通过LOAD_FAST字节码直接从当前栈帧中读取，几乎没有额外开销；而合并到main函数后，很多变量会落入全局作用域或者更大的嵌套作用域，解释器需要用LOAD_GLOBAL字节码从全局字典中查找，这一过程的耗时是LOAD_FAST的数倍。

举个简单的对比例子：

# 局部变量版本（更快）
def local_test():
    arr = [i for i in range(10**6)]
    total = 0
    for num in arr:
        total += num

# 全局变量版本（更慢）
arr = [i for i in range(10**6)]
def global_test():
    total = 0
    for num in arr:
        total += num

测试下来，local_test的运行速度会比global_test快20%以上，这就是作用域带来的直观差异。

2. CPU缓存命中率的影响 #

模块化的代码逻辑更紧凑，数据访问模式更规律——printKMax专注于滑动窗口的计算，会持续访问数组的连续片段，这非常符合CPU的缓存预取机制，能大幅提升L1/L2缓存的命中率；而非模块化版本中，输入处理和窗口计算混在一起，数据访问路径变得零散（一会儿读输入、一会儿算窗口），CPU缓存频繁失效，不得不从内存中读取数据，这会带来巨大的耗时开销。你的本地测试中37%的性能差距，很大一部分来自缓存命中率的差异。

3. 解释器的优化倾向 #

Python的字节码编译器会对结构清晰的小函数做更多优化：比如局部变量的寄存器缓存、循环体的内联优化等；而大的main函数因为变量多、逻辑复杂，解释器无法有效识别并优化关键路径，导致很多操作保留了原始的低效字节码。换句话说，模块化的代码让解释器更容易“看懂”你的核心逻辑，从而给出更精准的优化。

4. 函数调用开销被高估了 #

很多人担心函数调用的开销，但现代Python解释器（比如CPython 3.8+）已经大幅降低了函数调用的成本。相比之下，全局变量访问、缓存失效这些问题带来的开销，远大于函数调用的那点损耗。你以为合并代码减少了循环次数，但实际上并没有——滑动窗口的核心循环次数是固定的，反而因为作用域和缓存的问题，让每一次循环的耗时增加了。

总结 #

模块化的代码并非一定“更重”，反而因为局部作用域的高效访问、更优的缓存命中率、解释器的针对性优化，在大数据量测试用例中表现更好。你遇到的情况是典型的“直觉优化反被坑”，核心原因是忽略了底层运行机制的细节。

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