框架

传统上，当从流中反序列化对象时（通过调用 load() 而不是 loads()），可能会对类文件对象发出许多小的 read() 调用，这会对性能产生巨大的影响。

相比之下，协议 4 具有二进制框架。因此，pickle 的总体结构如下

+------+------+
| 0x80 | 0x04 |              protocol header (2 bytes)
+------+------+
|  OP  |                     FRAME opcode (1 byte)
+------+------+-----------+
| MM MM MM MM MM MM MM MM |  frame size (8 bytes, little-endian)
+------+------------------+
| .... |                     first frame contents (M bytes)
+------+
|  OP  |                     FRAME opcode (1 byte)
+------+------+-----------+
| NN NN NN NN NN NN NN NN |  frame size (8 bytes, little-endian)
+------+------------------+
| .... |                     second frame contents (N bytes)
+------+
  etc.

为了保持实现的简单性，禁止 pickle 操作码跨越帧边界。pickler 会注意不要生成此类 pickle，而 unpickler 会拒绝它们。此外，没有“最后一帧”标记。最后一帧只是以 STOP 操作码结束的帧。

编写良好的 C 实现不需要为框架层进行额外的内存复制，从而保留了总体（反）序列化的效率。

所有操作码的二进制编码

GLOBAL 操作码仍在协议 3 中使用，它使用 pickle 协议的所谓“文本”模式，这涉及在 pickle 流中查找换行符。这也使二进制框架的实现变得复杂。

协议 4 禁止使用 GLOBAL 操作码，并将其替换为 STACK_GLOBAL，这是一个从堆栈获取其操作数的新操作码。

序列化更多“可查找”的对象

默认情况下，pickle 只能序列化模块全局函数和类。支持其他类型的对象，例如未绑定方法 [4]，是一个常见的请求。实际上，对其中一些对象的第三方支持，例如绑定方法，是在 multiprocessing 模块中实现的 [5]。

来自 PEP 3155 的 __qualname__ 属性使得可以通过名称查找更多对象成为可能。使 STACK_GLOBAL 操作码接受点分隔名称将允许标准 pickle 实现支持所有这些类型的对象。

用于大型对象的 64 位操作码

当前协议版本将各种内置类型的对象大小（str、bytes）导出为 32 位整数。这禁止对大型数据进行序列化 [1]。需要新的操作码来支持非常大的 bytes 和 str 对象。

集合和冻结集合的原生操作码

许多常见的内置类型（例如 str、bytes、dict、list、tuple）具有专用操作码来提高序列化和反序列化时的资源消耗；但是，集合和冻结集合没有。添加此类操作码将是一个明显的改进。此外，专用集合支持可以帮助消除当前无法对自引用集合进行 pickle 的情况 [2]。

使用关键字参数调用 __new__

目前，如果 __new__ 强制使用仅关键字参数，则无法对类进行 pickle（或更确切地说，无法进行反序列化） [3]。需要一个新的特殊方法 (__getnewargs_ex__) 和一个新的操作码 (NEWOBJ_EX)。如果存在 __getnewargs_ex__ 方法，则必须返回一个包含两个元素的元组 (args, kwargs)，其中第一个元素是位置参数的元组，第二个元素是类 __new__ 方法的关键字参数的字典。

更好的字符串编码

短 str 对象当前的长度编码为 4 字节整数，这是一种浪费。具有 1 字节长度的特定操作码将使许多 pickle 变得更小。

更小的记忆化

PUT 操作码都需要一个显式索引来选择在记忆字典的哪个条目中记忆堆栈顶部的元素。但是，在实践中，这些数字是按顺序分配的。一个新的操作码 MEMOIZE 将改为将堆栈顶部的对象存储在等于记忆字典当前大小的索引处。这允许使用更短的 pickle，因为 PUT 操作码会为所有非原子数据类型发出。

预取

Serhiy Storchaka 建议用一个特殊的 PREFETCH 操作码（带有 2 或 4 字节参数）来代替框架，以明确声明已知的 pickle 块。大型数据可以保存在这些块之外。一个简单的 unpickler 应该能够跳过 PREFETCH 操作码并仍然正确解码 pickle，但良好的错误处理将需要检查 PREFETCH 长度是否落在操作码边界上。