如何解读Python中Dill的Pickling跟踪输出？——排查（反）序列化性能瓶颈

我来帮你拆解dill的trace输出，以及怎么用它定位（反）序列化的性能问题——毕竟我也踩过类似大对象序列化慢到崩溃的坑😅

先搞懂trace输出里的符号含义 #

dill的trace输出里的标记其实对应了它内部pickle操作的核心指令，我们一个个来解析：

• T4：这个标记代表dill正在处理**类对象（type）**的序列化，后面跟着的就是被序列化的类的完整路径（比如<class 'foo_package.base.model.BarModel'>）。数字4对应dill底层pickle的操作码（opcode），T是TYPE的缩写，opcode 4专门用来处理类型对象的序列化。
• D2：这个标记代表dill正在处理**字典对象（dict）**的序列化，后面的<dict object at 0x...>是字典在内存中的地址。数字2对应pickle的DICT操作码，负责序列化字典结构。
• 带#前缀的内容：这些是dill跟踪输出里的栈跟踪标记，用来表示当前序列化的层级或上下文。比如# T4表示当前栈顶正在处理一个类对象的序列化，# D2则表示栈顶是字典对象的序列化过程。当你看到多层###...的时候，说明序列化进入了更深的嵌套层级。

如何从trace里找性能瓶颈线索 #

1. 循环引用的线索 #

如果在trace输出中反复出现同一个内存地址的对象（比如同一个<dict object at 0x7f7de3832800>），而且是无规律的重复，那大概率存在循环引用。dill虽然支持处理循环引用，但序列化/反序列化时需要反复追踪这些引用，会大幅增加耗时。比如你看到某几个类或字典的地址反复出现在输出里，就要重点检查这些对象之间的引用关系。

2. 深层嵌套结构的线索 #

如果trace输出里出现大量连续的D2、T4，而且层级标记（###...）越来越多，说明你正在序列化一个深度嵌套的对象结构。每一层嵌套都需要dill递归处理，层级越深，递归次数越多，耗时自然就上去了。比如如果你的BarModel里嵌套了SessionOptions，SessionOptions又嵌套了XyzzyObject，还层层套着字典，那这个嵌套链就是性能杀手。

3. 高频出现的对象类型 #

如果某一类对象（比如某个枚举、某个自定义类）在trace里反复出现几十上百次，说明这个对象被大量引用，序列化时需要重复处理。比如你看到<enum 'ModelType'>频繁出现，可能你的模型里有大量实例都引用了这个枚举的同一个实例——虽然dill会缓存重复对象，但如果数量级太大，还是会拖慢速度。

额外的排查建议 #

既然你已经用__getstate__/__setstate__处理了numpy/pyarrow/pandas这类大对象，那可以试试这些方向进一步优化：

• 用dill.detect.objects()函数查看当前对象的引用链，直接定位循环引用的位置，这个比看trace输出更直观。
• 尝试临时设置dill.settings['recurse'] = False关闭递归序列化，看看哪些对象触发了深层递归，快速定位嵌套最深的部分。
• 针对反序列化慢的问题，虽然dill没有直接的反序列化trace功能，但你可以把序列化后的对象拆分成多个小部分，分别测试反序列化耗时，找到哪个部分是耗时大头。比如先单独序列化BarModel的字典部分，再单独序列化嵌套的SessionOptions，分开测试看哪个更慢。

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