flatbuffer vs boost vs cereal serialization size test

[headupinclouds]

Create a simple flatbuffer test and compare the combined SDK + model size with an equivalent boost serialization approach (after lib stripping, etc).

Tutorial: https://google.github.io/flatbuffers/flatbuffers_guide_tutorial.html

Relates to #5

[headupinclouds]

Write this boost-iostreams example:
https://github.com/ruslo/hunter/blob/develop/examples/Boost-iostreams/foo.cpp

using flatbuffers and compare the total SDK + file size. Will likely need to increase the _complexity of the data type to get a reasonable sense of size the file size overhead introduced by boost versioning, etc.

[headupinclouds]

Initial tests here: https://github.com/elucideye/drishti/tree/pr.flatbuffers

https://github.com/elucideye/drishti/tree/pr.flatbuffers/src/tests/serialize

[headupinclouds]

In pr.flatbuffers I'm adding a small serialization test to get a sense of post install/strip executable size and generated binary archives for each approach. Of course optimizing the combined sdk + archive size is very dependent on the target SDK and archive sizes for a particular application. Here is an initial look, and the archive can be experimented with to produce a few data points. The monster.* archives are based on the flatbuffers tutorial and are currently very small. This can be increased in size.

du -sh _install/xcode-hid-sections/bin/test-serialize-*
440K    _install/xcode-hid-sections/bin/test-serialize-boost
 60K    _install/xcode-hid-sections/bin/test-serialize-cereal
 48K    _install/xcode-hid-sections/bin/test-serialize-flatbuffers

-rw-r--r--  1 dhirvonen  wheel   96 Nov 13 13:35 /tmp/monster.cereal
-rw-r--r--  1 dhirvonen  wheel  152 Nov 13 13:35 /tmp/monster.fb
-rw-r--r--  1 dhirvonen  wheel   97 Nov 13 13:35 /tmp/monster.pba.z