Provide benchmarks on space efficiency

[letmaik]

The claim is "It's like JSON. but fast and small." However there are no numbers behind that, and in some cases this statement may not be true.

I did a quick test with a bigger GeoJSON file and arrived at the following sizes:

	normal	gzipped
idaho.json	10.92 MB	2.66 MB
idaho.msgpack	7.47 MB	4.50 MB

I'm really interested in what causes MessagePack to be less suitable for compression here. In the end this could result in a table stating in which scenarios it makes sense to use MessagePack and in which not.

[ludocode]

The reason you're seeing such a large size for MessagePack is because this data is mostly real numbers which you are converting to doubles rather than floats, even though the original JSON is using nowhere near the full range of doubles. This means each ~9 digit number in the JSON is converted to 8 bytes in MessagePack which is much less compressible. 9 decimal digits is about 30 bits of data, so the data probably comes from 4-byte floats in the first place.

Using json2msgpack -f to convert real numbers to floats instead of doubles, I get the following results:

	uncompressed	gzipped
idaho.geojson	10.9 MB	2.6 MB
idaho.mp (doubles)	7.5 MB	4.5 MB
idaho.mp (floats)	4.4 MB	2.2 MB

The gzipped space savings are modest, but using MessagePack for numerical data like this where the data is already in IEEE 754 is going to be much faster than parsing decimal strings into floats from JSON. (The performance difference may not be significant compared to the overhead of gzip though.)

[tagomoris]

Great comparison 👍
(I leave this opened for many others.)