Framing

Traditionally, when unpickling an object from a stream (by calling load() rather than loads()), many small read() calls can be issued on the file-like object, with a potentially huge performance impact.

Protocol 4, by contrast, features binary framing. The general structure of a pickle is thus the following:

+------+------+
| 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.

To keep the implementation simple, it is forbidden for a pickle opcode to straddle frame boundaries. The pickler takes care not to produce such pickles, and the unpickler refuses them. Also, there is no “last frame” marker. The last frame is simply the one which ends with a STOP opcode.

A well-written C implementation doesn’t need additional memory copies for the framing layer, preserving general (un)pickling efficiency.

Binary encoding for all opcodes

The GLOBAL opcode, which is still used in protocol 3, uses the so-called “text” mode of the pickle protocol, which involves looking for newlines in the pickle stream. It also complicates the implementation of binary framing.

Protocol 4 forbids use of the GLOBAL opcode and replaces it with STACK_GLOBAL, a new opcode which takes its operand from the stack.

Serializing more “lookupable” objects

By default, pickle is only able to serialize module-global functions and classes. Supporting other kinds of objects, such as unbound methods [4], is a common request. Actually, third-party support for some of them, such as bound methods, is implemented in the multiprocessing module [5].

The __qualname__ attribute from PEP 3155 makes it possible to lookup many more objects by name. Making the STACK_GLOBAL opcode accept dot-separated names would allow the standard pickle implementation to support all those kinds of objects.

64-bit opcodes for large objects

Current protocol versions export object sizes for various built-in types (str, bytes) as 32-bit ints. This forbids serialization of large data [1]. New opcodes are required to support very large bytes and str objects.

Native opcodes for sets and frozensets

Many common built-in types (such as str, bytes, dict, list, tuple) have dedicated opcodes to improve resource consumption when serializing and deserializing them; however, sets and frozensets don’t. Adding such opcodes would be an obvious improvement. Also, dedicated set support could help remove the current impossibility of pickling self-referential sets [2].

Calling __new__ with keyword arguments

Currently, classes whose __new__ mandates the use of keyword-only arguments can not be pickled (or, rather, unpickled) [3]. Both a new special method (__getnewargs_ex__) and a new opcode (NEWOBJ_EX) are needed. The __getnewargs_ex__ method, if it exists, must return a two-tuple (args, kwargs) where the first item is the tuple of positional arguments and the second item is the dict of keyword arguments for the class’s __new__ method.

Better string encoding

Short str objects currently have their length coded as a 4-bytes integer, which is wasteful. A specific opcode with a 1-byte length would make many pickles smaller.

Smaller memoization

The PUT opcodes all require an explicit index to select in which entry of the memo dictionary the top-of-stack is memoized. However, in practice those numbers are allocated in sequential order. A new opcode, MEMOIZE, will instead store the top-of-stack in at the index equal to the current size of the memo dictionary. This allows for shorter pickles, since PUT opcodes are emitted for all non-atomic datatypes.

Prefetching

Serhiy Storchaka suggested to replace framing with a special PREFETCH opcode (with a 2- or 4-bytes argument) to declare known pickle chunks explicitly. Large data may be pickled outside such chunks. A na?ve unpickler should be able to skip the PREFETCH opcode and still decode pickles properly, but good error handling would require checking that the PREFETCH length falls on an opcode boundary.