A Comparison Of Serialization Formats

Overview

When you want to save, send or receive data passed around in applications, there are many different serialization formats to choose from. What is the best choice for your use case? This page aims to help answer this question by comparing some of the most popular serialization formats used today.

The following serialization formats will be reviewed:

• CSV
• JSON
• Protobuf (Protocol Buffers)
• TOML
• XML
• YAML

Lets begin with a disclaimer: There is no one-size-fits-all serialization format — the best format for the jobs depends on things such as the type/amount of data that is being serialized and the software that will be reading it.

The examples in the following sections show how different formats store the same data. I chose a simple, repeatable data structure which was supported by all reviewed serialization formats (two Pokemon objects, each which had id, name, age and address fields). Note that many of these serialization formats can store non-repeatable, randomly structured data (in fact, all can except CSV)., so in a way I am tailoring to the lowest common denominator, which influences the results.

In each review section, a score between 1-3 is highlighted red, 4-6 orange, and 6-10 green.

CSV

CSV is well suited to storing large amounts of tabulated data in a human-readable format. It is not well suited to storing objects or hash table like data structures (unlike every other serialization format that is reviewed here).

CSV is not very well standardized. RFC 4180 was an attempt to standardize the format, however the name “CSV” may refer to files which are delimited by non-comma characters such as spaces, tabs or semi-colons. In fact, it used to be called Delimiter Separated Values (DSV), although unfortunately CSV seems like the more prevalent term these days. And the format of the data between the delimiters is completely user defined (e.g. there is no specified way of defining dates).

The CSV format allows an optional header line appearing as the first line in the file. If present, it contains field names for each value in a record. This header line is very useful the labelling the data and should almost always be present.

The CSV format is well supported, with CSV libraries available for almost every popular programming language. The popular data manipulation library pandas for Python can read in a CSV straight into a data table (called a Dataframe) with a simple one-line command of pd.read_csv('myfile.csv'). CSV is also really the only serialization format reviewed on this page which has good support in spreadsheet programs such as Excel (it is the only serialization format reviewed which makes sense to be read into Excel, as CSV enforces a tabular structure).

For a human-readable format, CSV is quite concise (see the File Size section for more info). However, it can be difficult to work out what column is what, especially when there are a large number of rows (there is only one header column right at the top of the file), there are a large number of columns (there is no requirement of the columns being equal-spaced, and so you end up counting the commas from the left), and/or if there are empty fields (i.e. ,,).

Example

id, name, age, address
4, Charmander, 12.34, Fire St
25, Pikachu, 56.78, Electric St

Review

JSON

JSON is a ubiquitous human-readable data serialization format that is supported by almost every popular programming language. JSON’s data structures closely represent common objects in many languages, e.g. a Python dict can be represented by a JSON object, and a Python list by a JSON array. Note there are caveats to this!

It is important to note that the JSON syntax does not support comments! This can be a blessing (but mostly a curse). For large amounts of data that get read into software and written back to disk, comments would be pretty much useless anyway because they would not be preserved when re-written to file. If you do need comments, the common workaround is to add a __comment__ name/value pair or similar to JSON objects. The name in a JSON object’s name/value pairs always has to be a string. It also does not support any type of date format.

Example

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

[
    {
        "id": 4,
        "name": "Charmander",
        "age": 12.34,
        "address": "Fire Street"
    },
    {
        "id": 25,
        "name": "Pikachu",
        "age": 56.78,
        "address": "Electric Street"
    }
]

Review

Protocol Buffers (Protobuf)

Protobuf is a binary serialization protocol developed by Google. Since it serializes to binary, it is not human readable (although you can still pick out strings when viewing the file as ASCII text, see the example below).

The types of data that Protobuf can contain are well defined and include common types such as strings, integers, floats and dates.

Example

#^R^Charmander^Z^Fire Street%<A2>@
^A^R^Pikachu^Z^Electric Street%<F1>'OA

Review

TOML

TOML (Tom’s Obvious, Minimal Language) is a newer (relative to the others in this review) human-readable serialization format. It is quite similar to YAML in that is is aimed towards configuration files, but is strives to be simpler format (YAML can get quite complex, and this can be seen in the much slower YAML parse times).

TOML has syntax highlighters for Atom, Visual Studio, Visual Studio Code and other IDEs.

TOML suffers from somewhat verbose syntax when it comes to expressing an array of objects (on in TOML speak, an array of tables). This can be seen in the example below where each pokemon object in the array is delimited with [[pokemon]].

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

[[pokemon]]
id = 4
name = "Charmander"
address = "Fire Street"
age = 12.34

[[pokemon]]
id = 25
name = "Pikachu"
address = "Electric Street"
age = 56.78

Review

XML

XML is a human-readable serialization protocol. A well known XML-like format is HTML which is used to determine the structure of web pages.

One disadvantage of XML is it’s verbosity. It’s descriptive end tags which require you to re-type the name of the element that is being closed adds to the byte count of XML data.

It is well standardized, with plenty of tooling available to generate XML and validate it with schemas. The specification for XML can be found at https://www.w3.org/TR/xml/.

XML supports both standard (DOM style) parsers and streaming (SAX style) parsers.

Example

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

<people>
    <person>
        <id>4</id>
        <name>Charmander</name>
        <age>12.34</age>
        <address>Fire St</address>
    </person>
    <person>
        <id>25</id>
        <name>Pikachu</name>
        <age>56.78</age>
        <address>Electric Street</address>
    </person>
</people>

Review

YAML

YAML (YAML Ain’t Markup Language)

The YAML specification is much larger the the JSON specification. YAML allows for relational data (references) using anchors (`). YAML gets some bonus style points since the YAML homepage is even displayed in YAML (https://yaml.org/).

YAML is a strict super-set of JSON, which means you can parse JSON with a YAML parser (the YAML parser will probably take longer though, so don’t use this trick with large amounts of JSON data!).

Example

1
2

- { id: 0, name: Charmander, age: 12.34, address: "Fire Street" }
- { id: 25, name: Pikachu, age: 56.78, address: "Electric Street" }

Review

Speed Comparison (Benchmarking)

The following libraries were used for the speed comparison tests:

Python v3.7 was used for all Python tests. C++17/GCC compiler was used for all C++ tests. Tests ran on a Debian machine running inside a virtual machine. The purpose of this test was to show relative performance between the different serialization formats, which should be not be affected by running inside a virtual machine.

As to be representative of how the serialization data might be used, all write tests where passed the same input data, either a vector (for the C++ tests) or a List (for the Python tests) of Person objects. Each Person contains an ID (an integer starting from 0), a name (random string of 5 ASCII chars), and address (random string of 30 ASCII chars) and an age (float). Each test was required to serialize the data to the required format (using the libraries mentioned above) and then write the serialized data to disk. All read tests performed the opposite task, reading a data file, deserializing and creating a vector/List of Person objects.

3 iterations of each test where performed, and the smallest run time of the three was selected as the most representative. Larger runtimes are typically the result of the OS performing extraneous tasks which should not be included in these runtimes.

It is also interesting to see how the serializations respond to a change in the data size. If the size of the data doubles, does it take twice as long to read/write (linear response), or does it behave differently (e.g. quadratic, \(log(n)\), …)?. This is called the complexity of the serialization algorithm. To test this, I increased the people array from 10,000 to 100,000 (increased by a factor of 10). This was the result…

The code that performed these tests can be found at https://github.com/gbmhunter/BlogAssets/tree/master/Programming/serialization-formats.

File Size Comparison

When serializing large amounts of data, another important aspect is the verbosity of the format. To compare the verbosity of the different formats, we can pass each format the same data, dump the data to disk, and compare the file sizes.

As expected, the file sizes grow linearly with the number of records stored (10x amount of data = 10x the file size).

Being the only binary, non-human readable format that was compared, it’s with no surprise that protobuf is the most concise format. Closely behind protobuf was CSV. Because CSV does not support irregular, non-flat data structures, it only requires a value delimiter (e.g. ,) and end of line character (e.g. \n).

Other Formats That Weren’t Considered

• Apache Avro: A binary-based data serialization standard by Apache.
• BSON. A binary format popularized by MongoDB that is based on JSON.
• CAN’N PROTO. A “cerealization protocol”…:-D. See their website for more details.
• JSON5. A superset of JSON which allows for multi-line strings, comments, single-quote string delimiters, and more.
• HOCON: A serialization format that seems popular in Java.
• MessagePack. This looks similar to protobuf (uses binary encoding). Has libraries for a wide variety of languages.
• SDLang: A XML-like serialization format (but without the angled brackets) with libraries available in .NET, Java, PHP, Ruby and other languages.
• XDR (RFC4506): The External Data Representation (XDR) is a well-used but specialized (i.e. the average developer does not use this protocol on a day-to-day basis) serialization protocol.