Python中+运算符、extend与itertools.chain合并列表的性能对比

一、核心机制差异：内存分配与计算时机

评估三者的性能差异前，首先需要理解CPython在底层对列表（PyListObject）的存储结构。Python列表本质上是一个动态的指针数组，其内部包含指向具体对象的元素指针数组ob_item、已使用元素长度ob_size以及预分配容量allocated。这三种合并方式对这块底层内存的处理截然不同。

• + 运算符（新建列表，全量拷贝）：调用CPython的list_concat函数。它不会修改任何一个输入列表，而是向操作系统申请一块全新的内存空间，大小恰好等于两个原列表元素数量之和（$len_a + len_b$）。接着，底层通过两次指针复制（类似memcpy）把两边的元素指针完整拷入新数组，并增加元素的引用计数。这意味着每次相加都会产生$O(N+M)$的空间消耗与时间开销。
• list.extend()（原地修改，动态扩容）：调用CPython的list_extend函数。它直接在原列表尾部追加元素。如果原列表预分配的超额容量（over-allocation buffer）足以容纳新元素，则仅执行一次连续内存指针拷贝；若容量不足，CPython会按照约1.125倍的增长策略（公式为newsize + (newsize >> 3) + 6）对原列表进行realloc。其额外内存开销为$O(1)$，均摊时间复杂度为$O(M)$。
• itertools.chain()（惰性管道，零拷贝引用）：调用底层C实现的chainobject结构。它在被创建时完全不复制任何元素指针，也不申请任何存储结果的列表内存，仅保存传入序列的迭代器指针。元素只有在外部调用next()或者被for循环显式消费时才会逐个产出。因此，其初始化时间与内存空间均为$O(1)$。

二、基准测试设计与可复现验证代码

为了客观测量三者在不同场景下的真实开销，测试设计需要覆盖以下三个典型维度：

1. 双大列表合并（物化为新列表）：测试常规业务中两个固定中大型列表（如各100,000项）合并时的绝对耗时与内存增长。
2. 海量小列表批量聚合：测试1,000个长度为100的列表聚合。这是最容易暴露算法复杂度陷阱的典型场景（例如错误使用sum(lists, [])）。
3. 仅遍历消费（流式处理）：合并后直接在for循环中进行访问，而不将其转换为显式list对象，以此观察迭代器带来的零分配收益。

以下是用于执行该测试的完整自包含Python代码。读者可以直接在本地Python 3.8+环境中运行：

import timeit
import itertools
import tracemalloc
import gc

# 1. 准备测试数据
SIZE_A = 100_000
SIZE_B = 100_000
list_a = list(range(SIZE_A))
list_b = list(range(SIZE_B))

# 准备1000个小列表（各100个元素）用于批量聚合测试
BATCH_COUNT = 1000
BATCH_SIZE = 100
list_of_lists = [list(range(BATCH_SIZE)) for _ in range(BATCH_COUNT)]

def bench_two_lists():
    print("--- 场景1：双列表合并（各 100,000 元素，执行 100 次）---")
    
    # + 运算符（创建新列表）
    t_plus = timeit.timeit(lambda: list_a + list_b, number=100)
    print(f"[+] 运算符耗时:             {t_plus * 1000:.2f} ms")

    # 原地 extend（不计 copy 原列表成本，纯粹原地扩容）
    # 为保证每次基准一致，先预备副本
    def run_extend():
        target = list_a.copy()
        target.extend(list_b)
    t_extend_with_copy = timeit.timeit(run_extend, number=100)
    print(f"[extend] (含原列表copy)耗时: {t_extend_with_copy * 1000:.2f} ms")

    # chain 并物化为新 list
    t_chain_list = timeit.timeit(lambda: list(itertools.chain(list_a, list_b)), number=100)
    print(f"[chain] 物化为 list 耗时:    {t_chain_list * 1000:.2f} ms")

    # chain 纯迭代消费（模拟 for item in pipeline: pass）
    def consume_chain():
        for _ in itertools.chain(list_a, list_b):
            pass
    t_chain_iter = timeit.timeit(consume_chain, number=100)
    print(f"[chain] 仅遍历消费耗时:       {t_chain_iter * 1000:.2f} ms")

def bench_multi_lists():
    print("\n--- 场景2：1,000 个小列表批量聚合（各 100 元素，执行 50 次）---")
    
    # 错误范式：循环中用 + 累加（或 sum(lists, [])）
    def sum_plus():
        res = []
        for sub in list_of_lists:
            res = res + sub
        return res
    t_loop_plus = timeit.timeit(sum_plus, number=50)
    print(f"[+ 循环累加] 耗时:           {t_loop_plus * 1000:.2f} ms")

    # 正确范式1：预分配空列表并使用 extend 循环
    def extend_loop():
        res = []
        for sub in list_of_lists:
            res.extend(sub)
        return res
    t_loop_extend = timeit.timeit(extend_loop, number=50)
    print(f"[extend 循环] 耗时:         {t_loop_extend * 1000:.2f} ms")

    # 正确范式2：使用 itertools.chain.from_iterable
    t_chain_from_iterable = timeit.timeit(
        lambda: list(itertools.chain.from_iterable(list_of_lists)), 
        number=50
    )
    print(f"[chain.from_iterable] 耗时: {t_chain_from_iterable * 1000:.2f} ms")

if __name__ == "__main__":
    gc.disable()
    bench_two_lists()
    bench_multi_lists()
    gc.enable()

三、性能数据深度对比与耗时剖析

在主流x86-64架构与Python 3.11环境下的测试结果展示了明显的梯度区分。下表整理了核心测试维度的对比数据：

核心现象的技术解释

从实测数据可以提炼出三个关键的技术因果关系：

• 为什么双列表转换时 list(chain(a, b)) 反而略慢于 +？
  list(chain(a, b)) 首先构造了chain迭代器对象，随后list()通过Python迭代器协议逐个调用tp_iternext索取元素并填入列表。而+运算符在C层面通过memcpy批量把ob_item内的指针拷入目标地址。对于固定且仅有两个列表的场景，连续内存块的底层拷贝开销远远小于数万次迭代器函数调用的额外开销。
• 为什么在多列表合并中 + 出现性能雪崩？
  如果在循环中使用res = res + sublist，当遍历到第$k$个子列表时，必须把前$k-1$个列表累加的所有元素全量拷贝到第$k$个新列表中。如果有$M$个列表、每个列表长度为$L$，其总复制次数为： $$\sum_{k=1}^{M} k \cdot L = O(M^2 \cdot L)$$ 这正是典型的二次方复杂度（$O(M^2)$），累加的列表数量越多，性能恶化越陡峭。
• 为什么 itertools.chain.from_iterable 表现优异？
  chain.from_iterable接收一个包含多个列表的外层可迭代对象，在C层面维护单一迭代器状态机。当外层转为list(...)时，避免了Python代码中手动执行for循环所带来的虚拟机指令解释开销，因此与经过调优的extend循环处于同一顶尖梯队。

四、选型决策与生产环境避坑指南

在实际工程开发中，开发者不应盲目追求单项速度极限，而应结合数据量级、内存限制、是否需要保留原始数据这三个核心约束进行选择。

常见问题与注意事项

• 解包语法 [*a, *b] 的性能如何？
  在Python 3.5引入PEP 448后，解包语法提供了极为优雅的书写方式。在底层字节码中，[*a, *b] 会调用 BUILD_LIST 和 LIST_EXTEND 指令。其实际耗时与 a + b 极其接近，并允许混合元组、集合等任意可迭代类型。对于两个序列的常规合并，解包写法完全可以作为 + 的等价替代。
• itertools.chain 是一次性迭代器吗？
  是的。chain 返回的是生成器型迭代器。一旦经过一次遍历，其内部状态即到达末尾。如果后续需要重复读取合并后的数据，必须在外部物化为 list 或在生成时使用 itertools.tee 复制管道。