顺带一提，擅长”打脸直觉”的系列我又补了一篇：Python 字符串与正则性能深度实战：7 组实测数据告诉你正则不总是更快。里面用 timeit 实测了 7 组场景，好些结论跟我原本以为的正好相反，强烈建议一读。
如果你也在做高频对象创建的性能优化，推荐这篇：Python 对象池深度实战：CPython 内存分配器与 slots 复用技巧。
一个让我怀疑人生的性能问题
上个月跑一个量化策略回测，每天要从 Parquet 文件里读 2GB 的分钟级行情数据。切片、转置、算协方差矩阵，一套操作下来，光是数据预处理就要 45 秒。
我看了一下 memory profiler 的输出——好家伙，每次切片都在创建新的 bytes 对象。2GB 数据切 200 次，等于临时分配了 400GB 内存，虽然 GC 会回收，但分配和拷贝本身已经把 CPU 吃满了。
然后我想起来 Python 有个玩意儿叫 memoryview，支持零拷贝切片。试了一下，同样的操作从 45 秒变成了 4.8 秒——几乎是 10 倍差距。
这篇文章就把我踩过的坑和优化思路整理出来。先讲原理，再上代码，最后给一个真实的量化数据处理案例。
先搞清楚：为什么普通切片要拷贝？
Python 里最常见的二进制数据处理方式是用 bytes：
data = b'\x00' * 100_000_000 # 100 MB
chunk = data[10_000_000:20_000_000] # 切片 10 MB
# 这一行创建了一个新的 bytes 对象，拷贝了 10 MB 数据你可能会想”切片不就是改一下指针吗？C 语言里数组切片不就 ptr + offset 的事？”
对 C 来说是这样。但 Python 的 bytes 对象是不可变的平坦数组，它没有”视图”的概念。当你写 data[10:20] 时，CPython 老老实实分配新内存、把 10 个字节拷过去，然后返回一个新的 bytes 对象。
100 MB 的原始数据，如果切 100 次，每次 1 MB，拷贝总量就是 100 MB——看起来不多？别忘了你还得等 GC 回收那 99 个临时对象。
memoryview 的底层原理：buffer protocol
Python 有一个叫 Buffer Protocol 的东西（PEP 3118），允许一个对象把自己的内部内存缓冲区暴露给另一个对象，不经过拷贝。
memoryview 就是这个协议的消费者——它不持有数据，只是一个”窗口”，指向原始数据的一块区域。切片 memoryview 只是调整这个窗口的起始偏移和长度，零数据拷贝。
画个图你就明白了：
原始 bytes 对象 (100 MB):
[========================================================================]
bytes 切片 (拷贝):
原始: [========================================================================]
新对象: [========] ← 10 MB 新内存分配 + 拷贝
memoryview 切片 (零拷贝):
原始: [========================================================================]
视图: [========] ← 只记录 offset=10M, length=10M，不分配
底层在 CPython 中就是一个 C 结构体：
// 简化版：memoryview 的内部表示
struct {
PyObject *obj; // 指向原始对象（阻止 GC 回收）
void *buf; // 指向数据的指针
Py_ssize_t len; // 长度
Py_ssize_t offset; // 起始偏移（切片时只改这个）
int format; // 数据类型格式（struct 风格）
int ndim; // 维度
// ...
};切片操作只改 offset 和 len，不动 buf。这就是为什么快。
基础用法：创建、切片、类型转换
从 bytes / bytearray 创建
import time
# === 普通 bytes 切片 ===
data = b'\x01\x02\x03' * 1_000_000 # 3 MB
t0 = time.perf_counter()
for _ in range(10000):
chunk = data[1000:2000]
t1 = time.perf_counter()
print(f"bytes 切片 ×10000: {t1 - t0:.4f}s")
# === memoryview 切片 ===
mv = memoryview(data)
t0 = time.perf_counter()
for _ in range(10000):
chunk = mv[1000:2000]
t1 = time.perf_counter()
print(f"memoryview 切片 ×10000: {t1 - t0:.4f}s")
# 输出:
# bytes 切片 ×10000: 0.1287s
# memoryview 切片 ×10000: 0.0042s
30 倍差距。而且这个差距随着切片次数线性放大。
用 struct 解析内存视图
memoryview 的切片还是 memoryview，要转换成 Python 数值需要用 struct 或者直接 .cast()：
import struct
# 模拟 C 结构体: int(4B) + float(4B) + char(1B)
packed = struct.pack('i f c', 42, 3.14, b'X')
# b'*\x00\x00\x00\xc3\xf5H@X'
mv = memoryview(packed)
# 解析 int（字节 0-3）
int_val = struct.unpack_from('i', mv, 0)[0]
print(int_val) # 42
# 解析 float（字节 4-7）
float_val = struct.unpack_from('f', mv, 4)[0]
print(float_val) # 3.14...
# 用 cast() 直接把 4-byte 窗口当 int 序列
mv_ints = mv[0:4].cast('i')
print(mv_ints[0]) # 42 — 零拷贝，不需要 struct.unpack
.cast(format) 是 memoryview 的大杀器：它只改”怎么看这块内存”的元数据，不拷贝。把 8 个字节 cast 成 2 个 int 或 1 个 double，底层同一个 buffer。
从 array.array 和 numpy 创建
import array
import numpy as np
# array.array 天然支持 buffer protocol
arr = array.array('d', [1.0, 2.0, 3.0, 4.0, 5.0])
mv_arr = memoryview(arr)
print(mv_arr[16:24].cast('d')[0]) # 3.0 — 偏移 2×8B
# numpy 也支持
np_arr = np.array([1, 2, 3, 4, 5], dtype=np.int32)
mv_np = memoryview(np_arr)
# 修改 memoryview 会影响 numpy 数组
mv_np.cast('i')[0] = 999
print(np_arr[0]) # 999 — 共享内存！
注意最后这个例子：通过 memoryview 修改数据会直接影响 numpy 数组。它们是同一块内存。
实战：量化数据高性能处理管道
回到开头说的量化回测场景。行情数据以二进制格式存储，每条记录 20 字节：
struct TickRecord {
uint32_t timestamp; // 4 bytes — Unix timestamp
float price; // 4 bytes — 成交价
float volume; // 4 bytes — 成交量
float bid; // 4 bytes — 买一价
float ask; // 4 bytes — 卖一价
};传统做法：
import struct
import time
RECORD_FMT = 'I f f f f' # 20 bytes per record
RECORD_SIZE = struct.calcsize(RECORD_FMT)
def parse_traditional(raw_data: bytes, num_records: int):
"""传统方式：逐条 unpack，每次创建新的 tuple"""
result = []
offset = 0
for _ in range(num_records):
record = struct.unpack_from(RECORD_FMT, raw_data, offset)
result.append(record)
offset += RECORD_SIZE
return result
# 100 万条记录 = 20 MB 数据
raw_data = b'\x00' * RECORD_SIZE * 1_000_000
t0 = time.perf_counter()
records = parse_traditional(raw_data, 1_000_000)
t1 = time.perf_counter()
print(f"传统方式: {t1 - t0:.3f}s")
print(f"内存: {len(records)} 个 tuple = ~56 MB")
memoryview 零拷贝方案：
def parse_zero_copy(raw_data: bytes, num_records: int):
"""零拷贝方式：只解析需要的字段"""
mv = memoryview(raw_data)
result = []
# 每条记录 20 字节，但我们只关心字段所在的偏移
for i in range(num_records):
base = i * 20
# 直接 cast 每个字段，不 unpack
ts = mv[base:base+4].cast('I')[0]
price = mv[base+4:base+8].cast('f')[0]
result.append((ts, price)) # 只取需要的字段
return result
更进一步——不做循环，用 numpy 批量读：
import numpy as np
def parse_numpy_batch(raw_data: bytes, num_records: int):
"""numpy 批量读取，提前计算偏移"""
mv = memoryview(raw_data)
# 所有 timestamp 在偏移 0, 20, 40, ... — numpy 可以跨步读取
arr = np.frombuffer(mv, dtype=[
('timestamp', 'u4'),
('price', 'f4'),
('volume', 'f4'),
('bid', 'f4'),
('ask', 'f4'),
], count=num_records)
return arr
性能对比（100 万条记录）：
# 环境: Python 3.11, Intel i7-13700
传统 struct.unpack × 1M: 2.847s
memoryview + cast × 1M: 0.612s (4.7×)
numpy.frombuffer × 1M: 0.018s (158×)
numpy 第三行只有 18ms，因为 np.frombuffer 是直接在原始内存上建视图——零拷贝 + 向量化处理。这就是为什么金融量化团队几乎全用 numpy/pandas 做数据管道。
memoryview 的局限和坑
坑1：memoryview 会阻止原始对象被 GC
def get_chunk():
data = b'\x00' * 100_000_000 # 100 MB
mv = memoryview(data)
return mv[10:20] # 返回一个 10 字节的切片
chunk = get_chunk()
# chunk 只用了 10 字节，但它抓着原始 100 MB 的引用！
# 那 100 MB 没法被 GC 回收
如果你只需要这 10 个字节长期使用，要显式释放原始引用：
chunk_bytes = bytes(chunk) # 拷贝出 10 字节，释放 100 MB
del chunk # 现在原始数据可以被 GC 了
坑2：不能修改 bytes，只能修改 bytearray
mv = memoryview(b'hello')
mv[0] = ord('H') # TypeError: cannot modify read-only memory
要修改就用 bytearray：
mv = memoryview(bytearray(b'hello'))
mv[0] = ord('H')
print(bytes(mv)) # b'Hello'
坑3：cast 的格式必须匹配内存布局
mv = memoryview(b'\x01\x02\x03\x04\x05')
mv.cast('I') # ValueError: memoryview: length is not a multiple of 'I'
# 'I' 是 4 字节，5 字节对齐不了
5 字节对齐不了 4 字节的 int，报错。解决方案是提前做好 padding 或者只取对齐长度：
mv[:4].cast('I') # 只取前 4 字节
坑4：memoryview 比较不是按内容
a = memoryview(b'abc')
b = memoryview(b'abc')
print(a == b) # True — 内容相同
print(a is b) # False — 不同对象
print(a == a[0:3]) # True
这个还好， 是按内容比较的。但要小心直接用于 dict key——memoryview 是 hashable 的，但 hash 基于内存地址而非内容。
什么时候该用 memoryview？决策流程
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 读取大文件、多次切片 | memoryview | 避免每次切片拷贝 |
| 解析二进制协议（网络包、文件格式） | memoryview + struct | 零拷贝偏移读取各字段 |
| 批量数值计算（>= 1000 条记录） | numpy.frombuffer | 向量化 + 零拷贝 |
| 原地修改二进制数据 | bytearray + memoryview | 可修改的内存视图 |
| 处理少量小型 bytes（<1KB） | 普通 bytes 切片 | 拷贝开销可忽略，代码更简单 |
| 跨进程共享内存 | mmap + memoryview | 操作系统级别的共享内存 |
进阶：mmap + memoryview 处理超大文件
当数据大到内存放不下的时候（比如 10GB+ 的行情数据文件），mmap 是最好的解决方案——让操作系统把文件映射到虚拟地址空间，按需加载页面：
import mmap
with open('market_data.bin', 'r+b') as f:
# 映射整个文件到内存地址空间（不会实际加载全部）
with mmap.mmap(f.fileno(), 0) as mm:
mv = memoryview(mm)
# 读第一条记录（零拷贝）
ts = mv[0:4].cast('I')[0]
price = mv[4:8].cast('f')[0]
print(f"第一条记录: ts={ts}, price={price}")
# 跳到文件的第 100 万条记录
offset = 1_000_000 * 20
price_at_1M = mv[offset+4:offset+8].cast('f')[0]
print(f"第100万条价格: {price_at_1M}")
整个过程：零内存分配、零拷贝、操作系统按需分页——即使文件 100GB 也只需要几 MB 的常驻内存。
FAQ
Q: memoryview 和 slice 返回的视图有什么区别？
关键区别在拷贝。普通 slice（如 data[10:20]）创建新对象+拷贝数据；memoryview[10:20] 只调整窗口偏移，不拷贝数据。前者 O(n)，后者 O(1)。
Q: memoryview 支持哪些源类型？
所有支持 buffer protocol 的类型都可以：bytes, bytearray, array.array, numpy.ndarray, mmap.mmap, ctypes 数组。可以通过 hasattr(obj, '__buffer__') 或尝试 memoryview(obj) 来检测。
Q: data[:100] 和 memoryview(data)[:100] 在什么场景下性能差异最大？
三种场景差异显著：(1) 高频切片——循环中切片数万次，memoryview 杜绝了累计拷贝；(2) 大对象切片——MB 级别数据，拷贝本身就很贵；(3) 嵌套切片——data[a:b][c:d] 会触发两次拷贝，mv[a:b][c:d] 零次。
Q: memoryview 能在 asyncio 中使用吗？
可以，但要注意：memoryview 不是线程安全的。如果在多个协程中修改同一个 bytearray 的 memoryview，需要加锁。读取操作是安全的（CPython GIL 保护），但写入必须同步。
总结
memoryview 不是银弹，但在它擅长的场景里确实是大杀器。
关键原则：
- 切片密集型操作（循环切片、嵌套切片）→ memoryview 零拷贝
- 二进制协议解析（网络包、文件格式）→ memoryview + struct/cast
- 批量数值计算（>1000 条记录）→ numpy.frombuffer（零拷贝 + 向量化）
- 超大文件处理（>内存的文件）→ mmap + memoryview
- 小数据、简单场景 → 普通 bytes，代码更可读
我在那个量化回测场景里，把数据预处理管道从 struct.unpack 循环改成 numpy.frombuffer(memoryview(...)) 之后，45 秒变成了 0.6 秒。不是优化，是重写。
有时候选对数据结构，比微调算法重要一百倍。
看完这篇有兴趣的话，可以再看看之前写的 Python slots 内存优化、Python 性能剖析三件套实战 和 Python GIL 与并发策略选择——这三篇加本文正好构成一套完整的数据密集型 Python 优化工具箱。
📖 相关阅读：Python itertools 惰性管道实战 — 用生成器管道替代千行循环，百万级数据处理快 3 倍、内存减半。