Framing

Traditionell kann beim Entpickeln eines Objekts aus einem Stream (durch Aufruf von `load() statt `loads()) viele kleine `read()-Aufrufe auf dem dateiähnlichen Objekt ausgegeben werden, was sich potenziell erheblich auf die Leistung auswirken kann.

Protokoll 4 zeichnet sich dagegen durch binäres Framing aus. Die allgemeine Struktur eines Pickles ist somit die folgende:

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

Um die Implementierung einfach zu halten, darf ein Pickle-Opcode keine Frame-Grenzen überschreiten. Der Pickler stellt sicher, keine solchen Pickles zu erzeugen, und der Unpickler lehnt sie ab. Außerdem gibt es keine Markierung für den „letzten Frame“. Der letzte Frame ist einfach derjenige, der mit einem STOP-Opcode endet.

Eine gut geschriebene C-Implementierung benötigt keine zusätzlichen Speicher kopien für die Framing-Schicht und erhält die allgemeine Effizienz der (Ent-)Serialisierung.

Binäre Kodierung für alle Opcodes

Der GLOBAL-Opcode, der in Protokoll 3 immer noch verwendet wird, nutzt den sogenannten „Textmodus“ des Pickle-Protokolls, der das Suchen nach Zeilenumbrüchen im Pickle-Stream beinhaltet. Dies erschwert auch die Implementierung von binärem Framing.

Protokoll 4 verbietet die Verwendung des GLOBAL-Opcodes und ersetzt ihn durch STACK_GLOBAL, einen neuen Opcode, der seinen Operanden vom Stack nimmt.

Serialisierung von mehr „nachschlagefähigen“ Objekten

Standardmäßig kann Pickle nur Modul-globale Funktionen und Klassen serialisieren. Die Unterstützung anderer Objekttypen, wie z. B. unbound methods [4], ist eine häufige Anforderung. Tatsächlich wird von Drittanbietern die Unterstützung für einige davon, wie z. B. bound methods, im multiprocessing-Modul implementiert [5].

Das Attribut `__qualname__` aus PEP 3155 ermöglicht das Nachschlagen vieler weiterer Objekte anhand ihres Namens. Wenn der STACK_GLOBAL-Opcode punktgetrennte Namen akzeptiert, kann die Standard-Pickle-Implementierung all diese Objekttypen unterstützen.

64-Bit-Opcodes für große Objekte

Aktuelle Protokollversionen exportieren Objektgrößen für verschiedene eingebaute Typen (str, bytes) als 32-Bit-Integer. Dies verbietet die Serialisierung großer Daten [1]. Neue Opcodes sind erforderlich, um sehr große Bytes- und String-Objekte zu unterstützen.

Native Opcodes für Mengen (sets) und unveränderliche Mengen (frozensets)

Viele gängige eingebaute Typen (wie str, bytes, dict, list, tuple) haben dedizierte Opcodes, um den Ressourcenverbrauch beim Serialisieren und Deserialisieren zu verbessern; Mengen (sets) und unveränderliche Mengen (frozensets) jedoch nicht. Das Hinzufügen solcher Opcodes wäre eine offensichtliche Verbesserung. Außerdem könnte die dedizierte Unterstützung für Mengen dazu beitragen, die derzeitige Unmöglichkeit, sich selbst referenzierende Mengen zu pickeln, zu beseitigen [2].

Aufruf von `__new__` mit Schlüsselwortargumenten

Derzeit können Klassen, deren `__new__` die Verwendung von nur-Schlüsselwortargumenten erzwingt, nicht gepickelt (oder besser gesagt, nicht entpickelt) werden [3]. Sowohl eine neue spezielle Methode (`__getnewargs_ex__`) als auch ein neuer Opcode (NEWOBJ_EX) sind erforderlich. Die Methode `__getnewargs_ex__`, falls vorhanden, muss ein Tupel aus zwei Elementen zurückgeben (`(args, kwargs)`), wobei das erste Element das Tupel der Positionsargumente und das zweite Element das Dictionary der Schlüsselwortargumente für die `__new__`-Methode der Klasse ist.

Bessere Zeichenkodierung

Kurze String-Objekte haben derzeit ihre Länge als 4-Byte-Integer kodiert, was verschwenderisch ist. Ein spezifischer Opcode mit einer 1-Byte-Länge würde viele Pickles kleiner machen.

Kleinere Memoization

Die PUT-Opcodes erfordern alle einen expliziten Index, um im Memo-Dictionary zu wählen, in welchem Eintrag das oberste Element des Stacks memoisiert wird. In der Praxis werden diese Nummern jedoch sequenziell zugewiesen. Ein neuer Opcode, MEMOIZE, speichert stattdessen das oberste Element des Stacks unter dem Index, der der aktuellen Größe des Memo-Dictionaries entspricht. Dies ermöglicht kürzere Pickles, da PUT-Opcodes für alle nicht-atomaren Datentypen ausgegeben werden.

Prefetching

Serhiy Storchaka schlug vor, das Framing durch einen speziellen PREFETCH-Opcode (mit einem 2- oder 4-Byte-Argument) zu ersetzen, um bekannte Pickle-Chunks explizit zu deklarieren. Große Daten können außerhalb solcher Chunks gepickelt werden. Ein naiver Unpickler sollte den PREFETCH-Opcode überspringen und Pickles trotzdem korrekt dekodieren können, aber eine gute Fehlerbehandlung erfordert die Überprüfung, ob die PREFETCH-Länge auf einer Opcode-Grenze liegt.