# Efficient Data Exchange between WebAssembly Modules
## 3 Related Work
### Serialization  
Considering that WASM is a compilation target for many programming languages and compilers, which implies different memory representations for each language, serializers can be used to establish a standardized data organization. This enables different languages to interpret and access information regardless of their internal memory structure. In this field, Google reported that 5% of its data center's computational cycles were dedicated to data serialization in 2015 [25], with estimates suggesting a potential increase [26]. Meta, formerly Facebook, disclosed that a mere 18% of CPU cycles were used for core application logic, with the remainder spent on common operations not central to app logic, such as I/O processing, logging, and compression. Serialization and deserialization alone could account for up to 14% of CPU cycles [27]. We compare several data serialization types most used in WASM and IPC:  
JSON (JavaScript Object Notation): JSON is widely recognized for its human-friendly text format and adaptability. It is schema-less, with no need for predefined data structures, and thus offers flexibility in data types and structures at the expense of computational efficiency. Its high readability and adaptability entail higher memory consumption for parsing and lack of random access, which make it less suitable for scenarios with heavy binary and numeric data communication. Google Protocol Buffers (Protobuf): A binary serialization framework that requires predefining data schemas. This enables more efficient data access due to the use of known data types. It has greater data compactness than JSON and is a superior choice for data transfer across networked devices. It requires generated code for each data structure [28] and often outperforms other serializers in resourceful environments but lacks random access reads and partial reads. MessagePack: This binary format aims to combine the best of JSON and Protobuf. It avoids the need for predefined schemas and operates in binary mode [29]. In general, MessagePack offers better efficiency than JSON without compromising on the self-describing feature. However, MessagePack does include metadata, which may lead to larger sizes than Protobuf, and it does not support random or partial decoding. Google FlatBuffers: Designed for performance, FlatBuffers allows in-place data access without a parsing step, making it fast and suitable for environments with limited resources. It demands predefined schemas but allows for partial data reads without full decoding, which enhances its efficiency. However, security concerns arise due to the absence of bounds checking. This potentially leads to sensitive data exposure or application crashes [30]. The generated code can be complex, as the optional bounds checking, when available, impacts performance and negates the advantage of random access [31]. Furthermore, each access may require one lookup-table due to dynamic structures and the possibility of omitting non-used fields. Cap'n'Proto: Developed by a former Google Protobuf developer, Cap'n'Proto is a binary serialization format that enables data reading without prior decoding while allowing for random and partial reads. It needs a schema and uses code generation for various languages and offers security benefits over FlatBuffers through built-in memory bounds checking. Although it introduces a slight performance penalty, it maintains efficiency by not requiring a full data scan for access [32]. Karmem: The initial versions of Karmem shared objectives with FlatBuffers and Cap'n'Proto. Karmem emphasized memory reuse and enabled random data access without the need for decoding. It used its schema and description language and supported various programming languages. Compared to other alternatives, initial versions of Karmem did not require any data transformation between big-endian and little-endian formats, and while it was limited to 4 GB and could not directly support arrays of arrays, it included bounds checking for each accessed field.