pickle在multiprocessing中特别慢，因其默认递归遍历对象图、维护引用表、打包类型与路径信息，并引发多次内存拷贝；实测传10MB ndarray耗时80ms，而shared_memory零拷贝仅需0.1ms。
别用 pickle 做高频、大数据量的进程间通信——它默认序列化+反序列化+多次内存拷贝，是性能瓶颈的根源。真正有效的优化不是“调参数”，而是换协议、换通道、绕过序列化本身。
为什么 pickle.dumps() 在 multiprocessing 中特别慢？
当你往 multiprocessing.Queue 或 multiprocessing.Pipe 里塞数据时，Python 默认会调用 pickle.dumps()；子进程收到后再调用 pickle.loads()。这个过程不只是“转成字节”，还包括：
- 递归遍历整个对象图（哪怕你只改了一个字段）
- 为每个对象生成唯一标识并维护引用表（防循环引用）
- 把所有类型信息、模块路径都打包进去（导致体积膨胀）
- 在多进程场景下，同一份数据可能被序列化→拷贝→反序列化→再序列化（比如中转进程）
实测：传一个 10MB 的 numpy.ndarray，pickle 耗时约 80ms；而用 shared_memory 零拷贝，耗时不到 0.1ms。
用 struct + memoryview 替代 pickle 传输固定结构数据
如果你的数据结构稳定（比如传感器采样点：时间戳 + 3个 float），根本不需要通用序列化。直接按 C 风格二进制布局写入共享内存或管道：
立即学习“Python免费学习笔记（深入）”；
- 用
struct.pack('dfff', ts, x, y, z)打包成紧凑字节串 - 用
memoryview(buf).cast('d')或numpy.frombuffer(buf, dtype='f8,f4,f4,f4')直接映射读取 - 避免任何 Python 对象构造开销，也不依赖
pickle协议版本兼容性
示例：传 10 万个点，struct 方式比 pickle 快 6 倍以上，且内存占用恒定。
跨语言或需兼容性时，优先选 MessagePack 而非 JSON
JSON 看似轻量，但 json.dumps() 输出的是 UTF-8 字符串，对数字/布尔值做文本转换，再加引号和逗号，体积大、解析慢；MessagePack 是二进制格式，天然匹配内存布局：
-
msgpack.packb({'x': 1.23, 'y': 4.56})输出比等效 JSON 少 30–50% 字节 - 无编码/解码字符串开销，
msgpack.unpackb()比json.loads()快 2–3 倍 - C#、Unity、Rust 等语言都有成熟、零配置的 msgpack 库，无需定义 schema
注意：msgpack 默认不支持 datetime 或自定义类，需显式注册扩展（用 msgpack.ExtType），否则会报 TypeError: can not serialize 'datetime'。
大数据块（如图像、矩阵）必须绕过序列化，走共享内存
一旦数据超过几 MB，无论用什么序列化协议，拷贝和编解码都是硬伤。此时唯一正解是让多个进程直接读写同一块物理内存：
- 用
multiprocessing.shared_memory.SharedMemory创建命名共享内存区 - 主进程把
numpy.ndarray的.data写入该区域（用shm.buf[:n] = arr.data） - 子进程通过同名
SharedMemory实例 attach 上来，再用numpy.ndarray(shape, dtype, buffer=shm.buf)重建视图 - 全程无序列化、无拷贝，延迟稳定在微秒级
容易踩的坑：SharedMemory 不自动管理生命周期，进程 crash 后 shm 可能残留；务必用 try/finally 或上下文管理器确保 .close() 和 .unlink() 调用。Windows 下还受限于命名规则（不能含反斜杠、长度≤260）。
