Figure 1
pickle serialization and deserialization process.
Table 1
Summary of main methods used by CPython’s pickle module.
| METHOD | DESCRIPTION | ARGUMENTS | RETURN VALUE |
|---|---|---|---|
| __reduce__ | Provides instructions on how to reconstruct an object during pickling. Returns a tuple that describes how to recreate the object. Typically contains a callable (e.g., function), arguments for that callable, and optionally the object’s state. | None | Tuple of (callable, args, state, optionally other items) |
| __reduce_ex__ | Similar to __reduce__, but allows different pickling protocols. Takes a protocol version to decide how to serialize an object. Used to add compatibility for different pickling versions. | protocol (int) – specifies the pickle protocol version | Same as __reduce__: a tuple of (callable, args, state, optionally other items) |
| __new__ | Used to create a new instance of a class without initializing it. Pickling uses __new__ to create an instance from a serialized state. It is called during unpickling before initialization. | cls (type), followed by optional arguments to initialize an instance | New instance of the class |
| __setstate__ | Allows for setting the state of an object during unpickling. Used to restore the object’s internal state from pickled data, called after the object is created via __new__. | state (dict, tuple, or other serialized data) – the state of the object | None (modifies the instance in place) |
Figure 2
mPickle architecture and module mapping. Arrows highlight the direction of data movement: from MicroPython to Python (dashed line), and from Python to MicroPython (dotted line). Continuous lines highlight the interaction to internally register functions and modules mapping.
Figure 3
mPickle examples workflow. Data objects can be serialized (dumped) in MicroPython using mPickle and deserialized (loaded) in CPython using native Pickle, and vice versa.
Figure 4
Comparison of serialized output sizes for JSON (dotted lines) and mPickle (continuous lines). Dots are the break-even points. The zoom-in plots highlight the break-even points regions, where mPickle becomes more efficient than JSON. (a) and (b) show the output sizes for lists and dictionaries, respectively. Finally, lower values are better.
Table 2
Break-Even points and space saving (percentage).
| STRUCTURE TYPE | DATA TYPE | BREAK-EVEN STRUCTURE SIZE | SAVING AT BREAK-EVEN | MAX SAVINGS (PERCENTAGE) | MAX SAVINGS STRUCTURE SIZE (ELEMENTS) |
|---|---|---|---|---|---|
| dict | float | 9 | 0.57 | 9.02 | 1000 |
| list | float | 19 | 0.46 | 8.91 | 2000 |
| dict | integer | 5 | 4.81 | 23.65 | 125 |
| list | integer | 6 | 4.23 | 49.34 | 2000 |
| dict | mixed | 6 | 1.52 | 15.38 | 125 |
| list | mixed | 9 | 1.68 | 24.0 | 2000 |
| dict | sequential | 9 | 1.85 | 23.12 | 250 |
| list | sequential | 14 | 4.34 | 54.74 | 250 |
Figure 5
Space saving in percentage of mPickle vs JSON. Negative values mean JSON is more efficient, while positive values mean mPickle is better. (a) and (b) show the space saving for lists and dictionaries, respectively. The dashed line indicates the break-even boundary. Finally, higher values are better.
Table 3
Main reuse scenarios enabled by mPickle across CPython (CP) and MicroPython (MP), mapped to the examples included.
| REUSE SCENARIO | WHAT IS SERIALIZED | DIRECTION | WHERE SHOWN |
|---|---|---|---|
| Core interoperability | Simple & built-in data types, nested structures | MP ↔ CP | Ex. 0 and 1 |
| Custom objects | User-defined classes and object state | MP ↔ CP | Ex. 2 |
| Embedded systems | Configurations, structured runtime state, parameters | MP ↔ CP | Ex. 0, 1 and 2 |
| Education and prototyping | Didactic examples, small projects, structured data exchange | MP ↔ CPython | Ex. 0, 1 and 2 |
| Numerical computing | NumPy arrays ↔ ulab arrays (via mapping) | MP ↔ CP | Ex. 3 |
| Edge AI artifacts | Model weights/layer params as dict of arrays | CP → MP (typical) | Ex. 4 |
| IoT integration | Sensor readings, batched records, device logs | MP/CP → server | Ex. 5 |
| Data science/experimentation | Structured objects and arrays moved to embedded targets | CP → MP (common) | Ex. 3, 4, and 5 |