1C++ Benchmarks {#flatbuffers_benchmarks} 2========== 3 4Comparing against other serialization solutions, running on Windows 7 564bit. We use the LITE runtime for Protocol Buffers (less code / lower 6overhead), Rapid JSON (one of the fastest C++ JSON parsers around), 7and pugixml, also one of the fastest XML parsers. 8 9We also compare against code that doesn't use a serialization library 10at all (the column "Raw structs"), which is what you get if you write 11hardcoded code that just writes structs. This is the fastest possible, 12but of course is not cross platform nor has any kind of forwards / 13backwards compatibility. 14 15We compare against Flatbuffers with the binary wire format (as 16intended), and also with JSON as the wire format with the optional JSON 17parser (which, using a schema, parses JSON into a binary buffer that can 18then be accessed as before). 19 20The benchmark object is a set of about 10 objects containing an array, 4 21strings, and a large variety of int/float scalar values of all sizes, 22meant to be representative of game data, e.g. a scene format. 23 24| | FlatBuffers (binary) | Protocol Buffers LITE | Rapid JSON | FlatBuffers (JSON) | pugixml | Raw structs | 25|--------------------------------------------------------|-----------------------|-----------------------|-----------------------|------------------------| ----------------------| ----------------------| 26| Decode + Traverse + Dealloc (1 million times, seconds) | 0.08 | 302 | 583 | 105 | 196 | 0.02 | 27| Decode / Traverse / Dealloc (breakdown) | 0 / 0.08 / 0 | 220 / 0.15 / 81 | 294 / 0.9 / 287 | 70 / 0.08 / 35 | 41 / 3.9 / 150 | 0 / 0.02 / 0 | 28| Encode (1 million times, seconds) | 3.2 | 185 | 650 | 169 | 273 | 0.15 | 29| Wire format size (normal / zlib, bytes) | 344 / 220 | 228 / 174 | 1475 / 322 | 1029 / 298 | 1137 / 341 | 312 / 187 | 30| Memory needed to store decoded wire (bytes / blocks) | 0 / 0 | 760 / 20 | 65689 / 4 | 328 / 1 | 34194 / 3 | 0 / 0 | 31| Transient memory allocated during decode (KB) | 0 | 1 | 131 | 4 | 34 | 0 | 32| Generated source code size (KB) | 4 | 61 | 0 | 4 | 0 | 0 | 33| Field access in handwritten traversal code | typed accessors | typed accessors | manual error checking | typed accessors | manual error checking | typed but no safety | 34| Library source code (KB) | 15 | some subset of 3800 | 87 | 43 | 327 | 0 | 35 36### Some other serialization systems we compared against but did not benchmark (yet), in rough order of applicability: 37 38- Cap'n'Proto promises to reduce Protocol Buffers much like FlatBuffers does, 39 though with a more complicated binary encoding and less flexibility (no 40 optional fields to allow deprecating fields or serializing with missing 41 fields for which defaults exist). 42 It currently also isn't fully cross-platform portable (lack of VS support). 43- msgpack: has very minimal forwards/backwards compatibility support when used 44 with the typed C++ interface. Also lacks VS2010 support. 45- Thrift: very similar to Protocol Buffers, but appears to be less efficient, 46 and have more dependencies. 47- YAML: a superset of JSON and otherwise very similar. Used by e.g. Unity. 48- C# comes with built-in serialization functionality, as used by Unity also. 49 Being tied to the language, and having no automatic versioning support 50 limits its applicability. 51- Project Anarchy (the free mobile engine by Havok) comes with a serialization 52 system, that however does no automatic versioning (have to code around new 53 fields manually), is very much tied to the rest of the engine, and works 54 without a schema to generate code (tied to your C++ class definition). 55 56### Code for benchmarks 57 58Code for these benchmarks sits in `benchmarks/` in git branch `benchmarks`. 59It sits in its own branch because it has submodule dependencies that the main 60project doesn't need, and the code standards do not meet those of the main 61project. Please read `benchmarks/cpp/README.txt` before working with the code. 62 63<br> 64