Currently a work in process. I plan on adding more methods of serializing data and adding a link to an article that will talk about this topic more in-depth.

To run the tests, type in go test -bench=. while in the main project directory.

Here are the results when run on my ubuntu machine.

goos: linux
goarch: amd64
pkg: serialization_comparison
BenchmarkMsgpackEnc-4            1839358               685 ns/op
BenchmarkMsgpackDec-4            1231225               969 ns/op
BenchmarkJsonEnc-4               1966341               604 ns/op
BenchmarkJsonDec-4                722858              1724 ns/op
BenchmarkMsgpackEnc_Long-4        770421              1713 ns/op
BenchmarkMsgpackDec_Long-4        381255              3028 ns/op
BenchmarkJsonEnc_Long-4           165088              7829 ns/op
BenchmarkJsonDec_Long-4            40827             29517 ns/op
BenchmarkTlvEnc_Chat-4           1642754               724 ns/op
BenchmarkTlvDec_Chat-4           1000000              1161 ns/op
BenchmarkMsgpackEnc_Chat-4        802418              1536 ns/op
BenchmarkMsgpackDec_Chat-4        769466              1625 ns/op
BenchmarkJsonEnc_Chat-4           913416              1107 ns/op
BenchmarkJsonDec_Chat-4           443504              2422 ns/op
PASS
ok      serialization_comparison        20.326s

The ones that are relevant to my chat application, nicknamed tin-can-communicator, are the last 12 that have _Chat-4 at the end of their names. Based on the results here, there are a few takeaways:

• The first is that MessagePack is much faster than Json, especially as the size of the data grows.

• The second is that decoding took much more time than encoding, which I found interesting.

• The final bit is that a type-length-value (TLV) style of protocol does allow someone to squeeze out some performance gains over Json or MessagePack. It would require you to maintain the protocol yourself, and to implement it for any new languages. Conversely, Json is essentially omnipresent and you could probably find some form of MessagePack in most languages that are popular. It may be worth it to create your own protocol when you truly need the extra performance and smaller payload size, but for most applications it would lead to negligible gains and an increase in tech-debt.