alecthomas/go_serialization_benchmarks

Benchmarks of Go serialization methods

Benchmarks of Go serialization methods

This is a test suite for benchmarking various Go serialization methods.

Tested serialization methods

• encoding/gob
• encoding/json
• github.com/json-iterator/go
• github.com/alecthomas/binary
• github.com/davecgh/go-xdr/xdr
• github.com/Sereal/Sereal/Go/sereal
• github.com/ugorji/go/codec
• github.com/vmihailenco/msgpack/v4
• labix.org/v2/mgo/bson
• github.com/tinylib/msgp (code generator for msgpack)
• google.golang.org/protobuf (generated code)
• github.com/gogo/protobuf (generated code, optimized version of goprotobuf)
• go.dedis.ch/protobuf (reflection based)
• github.com/google/flatbuffers
• github.com/hprose/hprose-go/io
• github.com/glycerine/go-capnproto
• zombiezen.com/go/capnproto2
• github.com/andyleap/gencode
• github.com/pascaldekloe/colfer
• github.com/linkedin/goavro
• github.com/ikkerens/ikeapack
• github.com/niubaoshu/gotiny
• github.com/prysmaticlabs/go-ssz
• github.com/200sc/bebop (generated code)
• github.com/shamaton/msgpackgen (generated code)
• github.com/mus-format/mus-go
• wellquite.org/bebop (generated code)
• github.com/deneonet/benc

Running the benchmarks

go get -u -t
go test -bench='.*' ./

To update the table in the README:

./stats.sh

Recommendation

If correctness and interoperability are the most important factors, protobuf and json do the job good. If speed matters, MUS and BENC are probably the best choice.

But as always, make your own choice based on your requirements.

Data

The data being serialized is the following structure with randomly generated values:

type A struct {
    Name     string
    BirthDay time.Time
    Phone    string
    Siblings int
    Spouse   bool
    Money    float64
}

Results

2023-11-16 Results with Go 1.21.4 linux/amd64 with processor 11th Gen Intel(R) Core(TM) i5-11300H @ 3.10GHz

benchmark	iter	time/iter	bytes/op	allocs/op	tt.sec	tt.kb	ns/alloc
Benchmark_Gotiny_Marshal-8	5175884	264 ns/op	48	168	1.37	24844	1.58
Benchmark_Gotiny_Unmarshal-8	7481815	145 ns/op	47	112	1.09	35905	1.30
Benchmark_GotinyNoTime_Marshal-8	4763344	268 ns/op	47	168	1.28	22859	1.60
Benchmark_GotinyNoTime_Unmarshal-8	9295584	130 ns/op	48	96	1.21	44618	1.36
Benchmark_Msgp_Marshal-8	12086298	110 ns/op	97	128	1.34	117237	0.86
Benchmark_Msgp_Unmarshal-8	6761966	186 ns/op	97	112	1.26	65591	1.67
Benchmark_VmihailencoMsgpack_Marshal-8	2206149	499 ns/op	92	264	1.10	20296	1.89
Benchmark_VmihailencoMsgpack_Unmarshal-8	1907919	600 ns/op	92	160	1.15	17552	3.75
Benchmark_Json_Marshal-8	1505756	770 ns/op	151	208	1.16	22842	3.70
Benchmark_Json_Unmarshal-8	674160	1670 ns/op	151	351	1.13	10220	4.76
Benchmark_JsonIter_Marshal-8	2389435	519 ns/op	141	200	1.24	33738	2.60
Benchmark_JsonIter_Unmarshal-8	1742654	677 ns/op	141	216	1.18	24623	3.14
Benchmark_EasyJson_Marshal-8	1491632	845 ns/op	151	896	1.26	22613	0.94
Benchmark_EasyJson_Unmarshal-8	2055382	535 ns/op	151	112	1.10	31159	4.78
Benchmark_Bson_Marshal-8	1733908	675 ns/op	110	376	1.17	19072	1.80
Benchmark_Bson_Unmarshal-8	1340866	864 ns/op	110	224	1.16	14749	3.86
Benchmark_MongoBson_Marshal-8	1374638	923 ns/op	110	240	1.27	15121	3.85
Benchmark_MongoBson_Unmarshal-8	1208486	999 ns/op	110	408	1.21	13293	2.45
Benchmark_Gob_Marshal-8	452556	3222 ns/op	162	1744	1.46	7354	1.85
Benchmark_Gob_Unmarshal-8	77752	16301 ns/op	162	7720	1.27	1264	2.11
Benchmark_XDR_Marshal-8	1408309	913 ns/op	92	440	1.29	12956	2.08
Benchmark_XDR_Unmarshal-8	1724904	664 ns/op	92	231	1.15	15869	2.88
Benchmark_UgorjiCodecMsgpack_Marshal-8	1722421	764 ns/op	91	1240	1.32	15674	0.62
Benchmark_UgorjiCodecMsgpack_Unmarshal-8	1552963	844 ns/op	91	688	1.31	14131	1.23
Benchmark_UgorjiCodecBinc_Marshal-8	1458865	872 ns/op	95	1256	1.27	13859	0.69
Benchmark_UgorjiCodecBinc_Unmarshal-8	1684272	910 ns/op	95	688	1.53	16000	1.32
Benchmark_Sereal_Marshal-8	818120	1693 ns/op	132	832	1.39	10799	2.03
Benchmark_Sereal_Unmarshal-8	523800	1940 ns/op	132	976	1.02	6914	1.99
Benchmark_Binary_Marshal-8	1156994	1030 ns/op	61	360	1.19	7057	2.86
Benchmark_Binary_Unmarshal-8	1309048	883 ns/op	61	320	1.16	7985	2.76
Benchmark_FlatBuffers_Marshal-8	2113926	565 ns/op	95	376	1.20	20141	1.51
Benchmark_FlatBuffers_Unmarshal-8	6082993	166 ns/op	95	112	1.01	57946	1.48
Benchmark_CapNProto_Marshal-8	980739	1092 ns/op	96	4392	1.07	9415	0.25
Benchmark_CapNProto_Unmarshal-8	3516151	320 ns/op	96	192	1.13	33755	1.67
Benchmark_CapNProto2_Marshal-8	1310677	1129 ns/op	96	1452	1.48	12582	0.78
Benchmark_CapNProto2_Unmarshal-8	3776460	410 ns/op	96	272	1.55	36254	1.51
Benchmark_Hprose_Marshal-8	2180806	499 ns/op	85	390	1.09	18589	1.28
Benchmark_Hprose_Unmarshal-8	1823271	746 ns/op	85	303	1.36	15554	2.46
Benchmark_Hprose2_Marshal-8	4629981	246 ns/op	85	0	1.14	39475	0.00
Benchmark_Hprose2_Unmarshal-8	3439027	346 ns/op	85	136	1.19	29328	2.55
Benchmark_Protobuf_Marshal-8	2780270	417 ns/op	52	144	1.16	14457	2.90
Benchmark_Protobuf_Unmarshal-8	2198923	503 ns/op	52	184	1.11	11434	2.74
Benchmark_Pulsar_Marshal-8	3066033	438 ns/op	51	304	1.35	15820	1.44
Benchmark_Pulsar_Unmarshal-8	3018387	428 ns/op	51	256	1.29	15547	1.67
Benchmark_Gogoprotobuf_Marshal-8	11825176	86 ns/op	53	64	1.02	62673	1.35
Benchmark_Gogoprotobuf_Unmarshal-8	7308174	140 ns/op	53	96	1.02	38733	1.46
Benchmark_Gogojsonpb_Marshal-8	180114	7772 ns/op	125	3095	1.40	2264	2.51
Benchmark_Gogojsonpb_Unmarshal-8	123753	8544 ns/op	125	3375	1.06	1554	2.53
Benchmark_Colfer_Marshal-8	15535346	84 ns/op	51	64	1.31	79339	1.32
Benchmark_Colfer_Unmarshal-8	11936880	122 ns/op	52	112	1.46	62071	1.09
Benchmark_Gencode_Marshal-8	12112273	107 ns/op	53	80	1.30	64195	1.34
Benchmark_Gencode_Unmarshal-8	8852018	142 ns/op	53	112	1.26	46915	1.27
Benchmark_GencodeUnsafe_Marshal-8	21924096	62 ns/op	46	48	1.37	100850	1.30
Benchmark_GencodeUnsafe_Unmarshal-8	10802174	110 ns/op	46	96	1.19	49690	1.15
Benchmark_XDR2_Marshal-8	12868144	110 ns/op	60	64	1.42	77208	1.72
Benchmark_XDR2_Unmarshal-8	17968026	66 ns/op	60	32	1.19	107808	2.07
Benchmark_GoAvro_Marshal-8	1000000	1246 ns/op	47	584	1.25	4700	2.13
Benchmark_GoAvro_Unmarshal-8	406524	3571 ns/op	47	2312	1.45	1910	1.54
Benchmark_GoAvro2Text_Marshal-8	570015	2303 ns/op	133	1320	1.31	7626	1.74
Benchmark_GoAvro2Text_Unmarshal-8	846238	1588 ns/op	133	736	1.34	11322	2.16
Benchmark_GoAvro2Binary_Marshal-8	1801123	672 ns/op	47	464	1.21	8465	1.45
Benchmark_GoAvro2Binary_Unmarshal-8	1789248	589 ns/op	47	544	1.05	8409	1.08
Benchmark_Ikea_Marshal-8	2166458	531 ns/op	55	184	1.15	11915	2.89
Benchmark_Ikea_Unmarshal-8	2764864	429 ns/op	55	160	1.19	15206	2.68
Benchmark_ShamatonMapMsgpack_Marshal-8	2728044	462 ns/op	92	192	1.26	25098	2.41
Benchmark_ShamatonMapMsgpack_Unmarshal-8	3132741	374 ns/op	92	168	1.17	28821	2.23
Benchmark_ShamatonArrayMsgpack_Marshal-8	3066362	374 ns/op	50	160	1.15	15331	2.34
Benchmark_ShamatonArrayMsgpack_Unmarshal-8	3704914	351 ns/op	50	168	1.30	18524	2.09
Benchmark_ShamatonMapMsgpackgen_Marshal-8	9664315	132 ns/op	92	96	1.28	88911	1.38
Benchmark_ShamatonMapMsgpackgen_Unmarshal-8	6034456	224 ns/op	92	112	1.35	55516	2.00
Benchmark_ShamatonArrayMsgpackgen_Marshal-8	10569614	100 ns/op	50	64	1.06	52848	1.57
Benchmark_ShamatonArrayMsgpackgen_Unmarshal-8	9751200	146 ns/op	50	112	1.43	48756	1.31
Benchmark_SSZNoTimeNoStringNoFloatA_Marshal-8	495163	2378 ns/op	55	440	1.18	2723	5.40
Benchmark_SSZNoTimeNoStringNoFloatA_Unmarshal-8	278251	3984 ns/op	55	1184	1.11	1530	3.36
Benchmark_Bebop_200sc_Marshal-8	14961906	81 ns/op	55	64	1.21	82290	1.27
Benchmark_Bebop_200sc_Unmarshal-8	20842504	61 ns/op	55	32	1.27	114633	1.91
Benchmark_Bebop_Wellquite_Marshal-8	17579114	72 ns/op	55	64	1.28	96685	1.13
Benchmark_Bebop_Wellquite_Unmarshal-8	20299090	66 ns/op	55	32	1.34	111644	2.06
Benchmark_FastJson_Marshal-8	3281961	382 ns/op	133	504	1.26	43912	0.76
Benchmark_FastJson_Unmarshal-8	1261986	919 ns/op	133	1704	1.16	16885	0.54
Benchmark_BENC_Marshal-8	21525518	65 ns/op	51	64	1.41	109780	1.02
Benchmark_BENC_Unmarshal-8	23009800	60 ns/op	51	32	1.39	117349	1.89
Benchmark_BENCUnsafe_Marshal-8	20615397	52 ns/op	51	64	1.08	105138	0.82
Benchmark_BENCUnsafe_Unmarshal-8	54961459	21 ns/op	51	0	1.21	280303	0.00
Benchmark_MUS_Marshal-8	18902049	64 ns/op	46	48	1.22	86949	1.35
Benchmark_MUS_Unmarshal-8	15403171	76 ns/op	46	32	1.18	70854	2.39
Benchmark_MUSUnsafe_Marshal-8	20805338	65 ns/op	49	64	1.35	101946	1.02
Benchmark_MUSUnsafe_Unmarshal-8	35980262	29 ns/op	49	0	1.06	176303	0.00

Totals:

benchmark	iter	time/iter	bytes/op	allocs/op	tt.sec	tt.kb	ns/alloc
Benchmark_BENCUnsafe_-8	75576856	74 ns/op	102	64	5.64	770883	1.17
Benchmark_MUSUnsafe_-8	56785600	94 ns/op	98	64	5.37	556498	1.48
Benchmark_BENC_-8	44535318	125 ns/op	102	96	5.61	454260	1.31
Benchmark_Bebop_Wellquite_-8	37878204	138 ns/op	110	96	5.25	416660	1.44
Benchmark_MUS_-8	34305220	140 ns/op	92	80	4.84	315608	1.76
Benchmark_Bebop_200sc_-8	35804410	142 ns/op	110	96	5.09	393848	1.48
Benchmark_GencodeUnsafe_-8	32726270	172 ns/op	92	144	5.65	301081	1.20
Benchmark_XDR2_-8	30836170	176 ns/op	120	96	5.44	370034	1.84
Benchmark_Colfer_-8	27472226	206 ns/op	103	176	5.68	283156	1.18
Benchmark_Gogoprotobuf_-8	19133350	226 ns/op	106	160	4.33	202813	1.42
Benchmark_ShamatonArrayMsgpackgen_-8	20320814	247 ns/op	100	176	5.03	203208	1.41
Benchmark_Gencode_-8	20964291	249 ns/op	106	192	5.23	222221	1.30
Benchmark_Msgp_-8	18848264	297 ns/op	194	240	5.61	365656	1.24
Benchmark_ShamatonMapMsgpackgen_-8	15698771	356 ns/op	184	208	5.60	288857	1.71
Benchmark_GotinyNoTime_-8	14058928	398 ns/op	95	264	5.61	134951	1.51
Benchmark_Gotiny_-8	12657699	410 ns/op	95	280	5.19	121501	1.47
Benchmark_Hprose2_-8	8069008	592 ns/op	170	136	4.78	137608	4.36
Benchmark_ShamatonArrayMsgpack_-8	6771276	725 ns/op	100	328	4.91	67712	2.21
Benchmark_FlatBuffers_-8	8196919	732 ns/op	190	488	6.00	156184	1.50
Benchmark_ShamatonMapMsgpack_-8	5860785	836 ns/op	184	360	4.90	107838	2.32
Benchmark_Pulsar_-8	6084420	867 ns/op	103	560	5.28	62736	1.55
Benchmark_Protobuf_-8	4979193	920 ns/op	104	328	4.59	51783	2.81
Benchmark_Ikea_-8	4931322	961 ns/op	110	344	4.74	54244	2.79
Benchmark_VmihailencoMsgpack_-8	4114068	1099 ns/op	184	424	4.52	75698	2.59
Benchmark_JsonIter_-8	4132089	1196 ns/op	282	416	4.94	116731	2.88
Benchmark_Hprose_-8	4004077	1245 ns/op	170	693	4.99	68289	1.80
Benchmark_GoAvro2Binary_-8	3590371	1261 ns/op	94	1008	4.53	33749	1.25
Benchmark_FastJson_-8	4543947	1302 ns/op	267	2208	5.92	121596	0.59
Benchmark_EasyJson_-8	3547014	1380 ns/op	303	1008	4.90	107545	1.37
Benchmark_CapNProto_-8	4496890	1412 ns/op	192	4584	6.35	86340	0.31
Benchmark_Bson_-8	3074774	1539 ns/op	220	600	4.73	67645	2.57
Benchmark_CapNProto2_-8	5087137	1539 ns/op	192	1724	7.83	97673	0.89
Benchmark_XDR_-8	3133213	1578 ns/op	184	671	4.95	57651	2.35
Benchmark_UgorjiCodecMsgpack_-8	3275384	1609 ns/op	182	1928	5.27	59611	0.83
Benchmark_UgorjiCodecBinc_-8	3143137	1783 ns/op	190	1944	5.60	59719	0.92
Benchmark_Binary_-8	2466042	1913 ns/op	122	680	4.72	30085	2.81
Benchmark_MongoBson_-8	2583124	1923 ns/op	220	648	4.97	56828	2.97
Benchmark_Json_-8	2179916	2440 ns/op	303	559	5.32	66116	4.37
Benchmark_Sereal_-8	1341920	3633 ns/op	264	1808	4.88	35426	2.01
Benchmark_GoAvro2Text_-8	1416253	3891 ns/op	267	2056	5.51	37898	1.89
Benchmark_GoAvro_-8	1406524	4817 ns/op	94	2896	6.78	13221	1.66
Benchmark_SSZNoTimeNoStringNoFloatA_-8	773414	6362 ns/op	110	1624	4.92	8507	3.92
Benchmark_Gogojsonpb_-8	303867	16316 ns/op	251	6470	4.96	7636	2.52
Benchmark_Gob_-8	530308	19523 ns/op	325	9464	10.35	17240	2.06

Issues

The benchmarks can also be run with validation enabled.

VALIDATE=1 go test -bench='.*' ./

Unfortunately, several of the serializers exhibit issues:

1. (minor) BSON drops sub-microsecond precision from time.Time.
2. (minor) Ugorji Binc Codec drops the timezone name (eg. "EST" -> "-0500") from time.Time.

--- FAIL: BenchmarkBsonUnmarshal-8
    serialization_benchmarks_test.go:115: unmarshaled object differed:
        &{20b999e3621bd773 2016-01-19 14:05:02.469416459 -0800 PST f017c8e9de 4 true 0.20887343719329818}
        &{20b999e3621bd773 2016-01-19 14:05:02.469 -0800 PST f017c8e9de 4 true 0.20887343719329818}
--- FAIL: BenchmarkUgorjiCodecBincUnmarshal-8
    serialization_benchmarks_test.go:115: unmarshaled object differed:
        &{20a1757ced6b488e 2016-01-19 14:05:15.69474534 -0800 PST 71f3bf4233 0 false 0.8712180830484527}
        &{20a1757ced6b488e 2016-01-19 14:05:15.69474534 -0800 -0800 71f3bf4233 0 false 0.8712180830484527}

All other fields are correct however.

Additionally, while not a correctness issue, FlatBuffers, ProtoBuffers, Cap'N'Proto, ikeapack and MUS do not support time types directly. In the benchmarks an int64 value is used to hold a UnixNano timestamp.

Bebop (both libraries, by nature of the format) natively supports times rounded to 100ns ticks, and this is what is currently benchmarked (a unix nano timestamp is another valid approach).

MUSUnsafe results were obtained using the mus-go unsafe package. With this package, after decoding a byte slice into a string, any change to this slice will change the contents of the string. In such cases, the slice can be reused only after processing the received result.

3. (major) Goprotobuf has been disabled in the above, as it is no longer maintained and is incompatible with the latest changes to Google's Protobuf package. See discussions: 1, 2.

panic: protobuf tag not enough fields in ProtoBufA.state:

goroutine 148 [running]:
github.com/gogo/protobuf/proto.(*unmarshalInfo).computeUnmarshalInfo(0xc0000d9c20)
	/home/ken/src/go/pkg/mod/github.com/gogo/[email protected]/proto/table_unmarshal.go:341 +0x135f
github.com/gogo/protobuf/proto.(*unmarshalInfo).unmarshal(0xc0000d9c20, {0xcff820?}, {0xc000122fc0, 0x35, 0x35})
	/home/ken/src/go/pkg/mod/github.com/gogo/[email protected]/proto/table_unmarshal.go:138 +0x67
github.com/gogo/protobuf/proto.(*InternalMessageInfo).Unmarshal(0xc00013a8c0?, {0xe6d5f0, 0xc000114060}, {0xc000122fc0?, 0x35?, 0x35?})
	/home/ken/src/go/pkg/mod/github.com/gogo/[email protected]/proto/table_unmarshal.go:63 +0xd0
github.com/gogo/protobuf/proto.(*Buffer).Unmarshal(0xc00009fe28, {0xe6d5f0, 0xc000114060})
	/home/ken/src/go/pkg/mod/github.com/gogo/[email protected]/proto/decode.go:424 +0x153
github.com/gogo/protobuf/proto.Unmarshal({0xc000122fc0, 0x35, 0x35}, {0xe6d5f0, 0xc000114060})
	/home/ken/src/go/pkg/mod/github.com/gogo/[email protected]/proto/decode.go:342 +0xe6
github.com/alecthomas/go_serialization_benchmarks.Benchmark_Goprotobuf_Unmarshal(0xc0000d5680)
	/home/ken/src/go/src/github.com/alecthomas/go_serialization_benchmarks/serialization_benchmarks_test.go:853 +0x26a
testing.(*B).runN(0xc0000d5680, 0x1)
	/usr/local/go/src/testing/benchmark.go:193 +0x102
testing.(*B).run1.func1()
	/usr/local/go/src/testing/benchmark.go:233 +0x59
created by testing.(*B).run1
	/usr/local/go/src/testing/benchmark.go:226 +0x9c
exit status 2
FAIL	github.com/alecthomas/go_serialization_benchmarks	61.159s

go_serialization_benchmarks's Issues

Limitations of the benchmarking

This benchmark is a bit comparing apples and oranges as the different encodings don't have the same properties.

Some just serialize the values without any type information (e.g.MUS), some add a type tag to the serialized value (e.g. MessagePack), and others add struct/object type name and field names (e.g. gob, json).

Most serializing package require code generation and some don't (e.g. gob, json).

Some encodings are thus very robust against bugs or malicious data, and some support dynamic value type discovery.
This is fine as the best choice depends on the type of usage and their requirements. But this has an impact on the speed and the encoded data size of the respective encoder/decoders.

A first suggestion is to add a table in the README listing the properties of the different packages.

A second suggestion is to group benchmarks by properties so that we don't compare apples with oranges.

gob: unknown type id or corrupted data

This is more question about go, rather than about benchmark. In gob serializer init function, after removing thees line

go_serialization_benchmarks/serialization_benchmarks_test.go

Line 406 in 6f010e2

err := s.enc.Encode(A{})

go_serialization_benchmarks/serialization_benchmarks_test.go

Line 411 in 6f010e2

err = s.dec.Decode(&a)

Unmarshal function returns unmarshal error gob: unknown type id or corrupted data. Could you please explain this?

Thank you

Report allocs

Benchmarks should be run with b.ReportAllocs turned on.

capnproto misuse

With regards to capnproto, capnproto bytes actually requires much less time (no additional beyond the I/O time for C++ code, and minimal for Go) to decode.

Your application code example is introducing extra unnecessary copying. To avoid this, use the Bytes() methods commented below to point to the strings in memory rather than copy them unnecessarily.

from https://github.com/alecthomas/go_serialization_benchmarks/blob/master/serialization_benchmarks_test.go#L496

func (x *CapNProtoSerializer) Unmarshal(d []byte, i interface{}) error {
    a := i.(*A)
    s, _, _ := capn.ReadFromMemoryZeroCopy(d)
    o := ReadRootCapnpA(s)
    a.Name = string(o.Name())  // declare Name to be []byte, and use NameBytes() to minimize copying/allocation
    a.BirthDay = time.Unix(o.BirthDay(), 0)
    a.Phone = string(o.Phone())  // as above, use PhoneBytes()
    a.Siblings = int(o.Siblings())
    a.Spouse = o.Spouse()
    a.Money = o.Money()
    return nil
}

Rerun with Go 1.4

Hello,

Maybe you can rerun benchmarks with Go 1.4. encoding/gob was completely rewritten in this release.

Gogoprotobuf Alternative?

Hi.

I hope you are having a great new year so far. With gogoprotobuf being deprecated by the author, which option would you recommend in its place?

Thanks in advance.

easyjson is missing

easyjson seems to be much better json encoder/decoder option but is missing in your benchmarks.

https://github.com/mailru/easyjson

Add Go Protobuf APIv2 tests

Go Protobuf has a new major version: https://blog.golang.org/protobuf-apiv2. It would be nice to add it to the benchmarks for a comparison.

Add Result Size Information

It would be interesting to show the produced binary/encoding size.

Generate* functions seem to not be equivalent

I noticed that the generate* call varies with the benchmark. This may lead to bad comparisons between formats.

In particular, FlatBuffers uses the original generate call, whereas GogoProtoBuf uses generateGogoProto.

Am I right in understanding this?

Document go version

In order to compare gob we would need to know what go version was used for the run in the README.

mgo bson uses deprecated import

line 20 of the serialisation test file

old, deprecated, uses BZR
"labix.org/v2/mgo/bson"

new, uses GIT
"gopkg.in/mgo.v2/bson"

JSON benchmarks corrupted

I found it very strange that the encoding and decoding benchmark results for encoding/json are almost the same while in pretty much any other benchmark you'll find online the decoding speed is way slower.

Additionally the speed of JsonIter seemed rather slow compared to EasyJson while in reality they should be pretty close.

After digging around a bit I found that structdef_easyjson.go > MarshalJSON() and structdef_easyjson.go > UnmarshalJSON() were the culprit. These apparently override functions in both of the other libraries and thus alter their results.
Renaming them fixes the JSON benchmarks:

structdef_easyjson.go:

func (v *A) MarshalJSON2() ([]byte, error) {
	w := jwriter.Writer{}
	easyjson_encode_go_serialization_benchmarks_A(&w, v)
	return w.Buffer.BuildBytes(), w.Error
}
func (v *A) MarshalEasyJSON(w *jwriter.Writer) {
	easyjson_encode_go_serialization_benchmarks_A(w, v)
}
func (v *A) UnmarshalJSON2(data []byte) error {
	r := jlexer.Lexer{Data: data}
	easyjson_decode_go_serialization_benchmarks_A(&r, v)
	return r.Error()
}

serialization_benchmarks_test.go:

func (m EasyJSONSerializer) Marshal(o interface{}) []byte {
	out, _ := o.(*A).MarshalJSON2()
	return out
}
func (m EasyJSONSerializer) Unmarshal(d []byte, o interface{}) error {
	err := o.(*A).UnmarshalJSON2(d)
	return err
}

JsonIter can further be sped up by using jsoniter.ConfigFastest:

Buffer Reuse Inconsistency

Some marshalers reuse the buffer. For example, Gotiny applies an encoder which always returns the same buffer. For a better comparison it should allocate the bytes like the others do.

An other option is to allow each codec to use the fastest option available, including buffer reuse. Or, we could measure both with a clear distinction for the reuse case, like b.Run("reuse", ….

The issue was noted by @inkeliz with his Karmen format.

go-xdr now supports time.Time

Now that go-xdr propertly supports time.Time (and has been confirmed with VALIDATE=1), the README should be updated accordingly.

Fair Comparison For FlatBuffer Lazy Parsing

BenchmarkFlatBuffersUnmarshal measures the performance of goserbench.FlatBufferA.Init which does only the initiation. Most of the work is done in the "getters".
To be fair, we could read the fields into a goserbench.A instance.

panic: not implemented

I am using version 3.11.4 of protocol buffers and Go 1.14.2

$ protoc --version
libprotoc 3.11.4

When running
$ go test -bench='.*' ./

I get the following
A test suite for benchmarking various Go serialization methods.

See README.md for details on running the benchmarks.

goos: linux
goarch: amd64
pkg: github.com/alecthomas/go_serialization_benchmarks
BenchmarkGotinyMarshal-8                        	13304299	        89.4 ns/op	        48.0 B/serial	       0 B/op	       0 allocs/op
BenchmarkGotinyUnmarshal-8                      	 6830947	       178 ns/op	        48.0 B/serial	     112 B/op	       3 allocs/op
BenchmarkGotinyNoTimeMarshal-8                  	12590604	        89.3 ns/op	        48.0 B/serial	       0 B/op	       0 allocs/op
BenchmarkGotinyNoTimeUnmarshal-8                	 7424698	       160 ns/op	        48.0 B/serial	      96 B/op	       3 allocs/op
BenchmarkMsgpMarshal-8                          	 9219133	       132 ns/op	        97.0 B/serial	     128 B/op	       1 allocs/op
BenchmarkMsgpUnmarshal-8                        	 4838880	       234 ns/op	        97.0 B/serial	     112 B/op	       3 allocs/op
BenchmarkVmihailencoMsgpackMarshal-8            	 1556703	       753 ns/op	       100 B/serial	     288 B/op	       4 allocs/op
BenchmarkVmihailencoMsgpackUnmarshal-8          	 1289294	       942 ns/op	       100 B/serial	     160 B/op	       9 allocs/op
BenchmarkJsonMarshal-8                          	  504692	      2342 ns/op	       152 B/serial	     944 B/op	       6 allocs/op
BenchmarkJsonUnmarshal-8                        	  467035	      2513 ns/op	       152 B/serial	     344 B/op	       6 allocs/op
BenchmarkJsonIterMarshal-8                      	  813463	      1338 ns/op	       152 B/serial	     952 B/op	       7 allocs/op
BenchmarkJsonIterUnmarshal-8                    	  515895	      2167 ns/op	       152 B/serial	     447 B/op	      14 allocs/op
BenchmarkEasyJsonMarshal-8                      	 1000000	      1111 ns/op	       152 B/serial	     784 B/op	       5 allocs/op
BenchmarkEasyJsonUnmarshal-8                    	 1089238	      1091 ns/op	       152 B/serial	     160 B/op	       4 allocs/op
BenchmarkBsonMarshal-8                          	 1269421	       884 ns/op	       110 B/serial	     392 B/op	      10 allocs/op
BenchmarkBsonUnmarshal-8                        	  926041	      1277 ns/op	       110 B/serial	     244 B/op	      19 allocs/op
BenchmarkGobMarshal-8                           	 2198652	       549 ns/op	        63.6 B/serial	      48 B/op	       2 allocs/op
BenchmarkGobUnmarshal-8                         	 2226387	       588 ns/op	        63.7 B/serial	     112 B/op	       3 allocs/op
BenchmarkXDRMarshal-8                           	  942240	      1265 ns/op	        92.0 B/serial	     455 B/op	      20 allocs/op
BenchmarkXDRUnmarshal-8                         	 1000000	      1085 ns/op	        92.0 B/serial	     239 B/op	      11 allocs/op
BenchmarkUgorjiCodecMsgpackMarshal-8            	 1342996	       882 ns/op	        91.0 B/serial	    1312 B/op	       3 allocs/op
BenchmarkUgorjiCodecMsgpackUnmarshal-8          	 1333430	       962 ns/op	        91.0 B/serial	     496 B/op	       4 allocs/op
BenchmarkUgorjiCodecBincMarshal-8               	 1216729	       950 ns/op	        95.0 B/serial	    1328 B/op	       4 allocs/op
BenchmarkUgorjiCodecBincUnmarshal-8             	 1000000	      1061 ns/op	        95.0 B/serial	     640 B/op	       7 allocs/op
BenchmarkSerealMarshal-8                        	  613936	      2004 ns/op	       132 B/serial	     904 B/op	      20 allocs/op
BenchmarkSerealUnmarshal-8                      	  509361	      2359 ns/op	       132 B/serial	    1008 B/op	      34 allocs/op
BenchmarkBinaryMarshal-8                        	 1000000	      1063 ns/op	        61.0 B/serial	     326 B/op	      21 allocs/op
BenchmarkBinaryUnmarshal-8                      	 1000000	      1118 ns/op	        61.0 B/serial	     320 B/op	      22 allocs/op
BenchmarkFlatBuffersMarshal-8                   	 5044725	       236 ns/op	        95.2 B/serial	       0 B/op	       0 allocs/op
BenchmarkFlatBuffersUnmarshal-8                 	 6249824	       191 ns/op	        95.2 B/serial	     112 B/op	       3 allocs/op
BenchmarkCapNProtoMarshal-8                     	 3490287	       309 ns/op	        96.0 B/serial	      56 B/op	       2 allocs/op
BenchmarkCapNProtoUnmarshal-8                   	 3719278	       332 ns/op	        96.0 B/serial	     200 B/op	       6 allocs/op
BenchmarkCapNProto2Marshal-8                    	 2531958	       539 ns/op	        96.0 B/serial	     244 B/op	       3 allocs/op
BenchmarkCapNProto2Unmarshal-8                  	 2005264	       631 ns/op	        96.0 B/serial	     320 B/op	       6 allocs/op
BenchmarkHproseMarshal-8                        	 1711749	       659 ns/op	        85.3 B/serial	     353 B/op	       8 allocs/op
BenchmarkHproseUnmarshal-8                      	 1392330	       869 ns/op	        85.3 B/serial	     319 B/op	      10 allocs/op
BenchmarkHprose2Marshal-8                       	 2824647	       427 ns/op	        85.3 B/serial	       0 B/op	       0 allocs/op
BenchmarkHprose2Unmarshal-8                     	 2624437	       442 ns/op	        85.3 B/serial	     144 B/op	       4 allocs/op
BenchmarkProtobufMarshal-8                      	 2087547	       569 ns/op	        52.0 B/serial	     152 B/op	       7 allocs/op
BenchmarkProtobufUnmarshal-8                    	 1331026	       904 ns/op	        52.0 B/serial	     280 B/op	      16 allocs/op
panic: not implemented

goroutine 169 [running]:
github.com/golang/protobuf/proto.(*InternalMessageInfo).Size(...)
	/home/tepkes/Development/Go/pkg/mod/github.com/golang/[email protected]/proto/deprecated.go:91
github.com/alecthomas/go_serialization_benchmarks.(*ProtoBufA).XXX_Size(0xc00073ce60, 0xe8f240)
	/home/tepkes/Projects/Serialization/go_serialization_benchmarks/structdef.pb.go:52 +0x39
github.com/gogo/protobuf/proto.Marshal(0xe8f240, 0xc00073ce60, 0x21c, 0x5eb00fab, 0xc000421ef8, 0x48b936, 0x5eb00fab)
	/home/tepkes/Development/Go/pkg/mod/github.com/gogo/[email protected]/proto/table_marshal.go:2938 +0x278
github.com/alecthomas/go_serialization_benchmarks.BenchmarkGoprotobufMarshal(0xc0000d4540)
	/home/tepkes/Projects/Serialization/go_serialization_benchmarks/serialization_benchmarks_test.go:830 +0xd6
testing.(*B).runN(0xc0000d4540, 0x1)
	/usr/lib/go-1.14/src/testing/benchmark.go:191 +0xe8
testing.(*B).run1.func1(0xc0000d4540)
	/usr/lib/go-1.14/src/testing/benchmark.go:231 +0x57
created by testing.(*B).run1
	/usr/lib/go-1.14/src/testing/benchmark.go:224 +0x7d
exit status 2
FAIL	github.com/alecthomas/go_serialization_benchmarks	62.291s
FAIL

Build broken: goavro v2 support

Currently unable to benchmark locally:

$ go get -u -t
# github.com/alecthomas/go_serialization_benchmarks
./structdef_avro.go:11:10: undefined: goavro.Record

Need to support v1 and v2 versions. Quick fix is changing current import from "github.com/linkedin/goavro" to goavro "gopkg.in/linkedin/goavro.v1"

Feature request: add benchmark for google protobuf

As golang protobuf readme said:

It has been superseded by the google.golang.org/protobuf module, which contains an updated and simplified API, support for protobuf reflection, and many other improvements. We recommend that new code use the google.golang.org/protobuf module.

Could you provide the comparison with https://github.com/protocolbuffers/protobuf-go?

Command, go get -u -t get error

clone the repository and run the command go get -u -t will get the following errors.

go get: github.com/itsmontoya/[email protected] updating to
        github.com/itsmontoya/[email protected]: parsing go.mod:
        module declares its path as: github.com/mojura/enkodo
                but was required as: github.com/itsmontoya/mum

I don't really understand the benchmark in the sense that...

tiny msgpack seems faster per iteration BUT gob is faster than tinymsgpack overall?

which is faster anyway? and what's the size of encoded result?

Include gogoprotobuf

It's quite a lot faster than goprotobuf.

README Not Updated for New vitess bson Path

The code imports "github.com/youtube/vitess/go/bson" however the README contains:

To run:

go get -u \
    ...
    code.google.com/p/vitess/go/bson \
    ...
go test -bench='.*' ./

This should be updated to:

go get -u \
    ...
    github.com/youtube/vitess/go/bson \
    ...
go test -bench='.*' ./

Skip running benchmarks for X if X fails to build

Running command "go test -bench='.*' ./" results in this error:

#github.com/niubaoshu/gotiny
../../golang/pkg/mod/github.com/niubaoshu/[email protected]/unsafe.go:47:3: //go:linkname must refer to declared function or variable
FAIL	github.com/alecthomas/go_serialization_benchmarks [build failed]
FAIL

Seems like the issue is specifically with niubaoshu/gotiny package. I'm not interested in this package yet it's a shame because of this I cannot run any other benchmarks and forced to take time to fix this first.

So hoping if it's possible to update such that if package X fails to build then skips it but build and run everything else?

I think it should be warned that gogo/protobuf is almost discontinued

I think it should be warned that https://github.com/gogo/protobuf is almost discontinued.

msgp

https://github.com/philhofer/msgp
It need go generate

@philhofer

correction to claim that go-capnproto truncates times

With regards to go-capnproto, it is inaccurate and misleading to claim that the serialization format is what is truncating off the nanoseconds. Rather, when you set the time in your application code, you yourself are doing the truncation. Referencing:

c2d096a#diff-f17176f7f172638627ca7eb38f7d873cR485

If you wish to store nanoseconds, then use UnixNano() instead of Unix().

Some "clever" optimizations used by some libs

One particular example is reusing/sharing data for incoming []byte

package main

import (
	"fmt"

	"github.com/shamaton/msgpack"
)

func main() {
	type Struct struct {
		String string
	}
	v := Struct{String: "msgpack"}

	d, err := msgpack.Encode(v)
	if err != nil {
		panic(err)
	}

	r := Struct{}
	err = msgpack.Decode(d, &r)
	if err != nil {
		panic(err)
	}

	fmt.Println("before", r.String)

	// Overwrite []byte
	for i := range d {
		d[i] = 1
	}

	fmt.Println("after", r.String)
}

The result is

before msgpack
after �������

I personally think it is an unacceptable practice and is not usable in the real world. WDYT?

I don't really understand the benchmark in the sense that...

tiny msgpack seems faster per iteration BUT gob is faster than tinymsgpack overall?

which is faster anyway? and what's the size of encoded result?

FlatBuffers

https://github.com/google/flatbuffers

Go library:
http://godoc.org/github.com/google/flatbuffers/go

gob fairness

Hi.
Why not using the same instance of gob Encoder/Decoder, instead of creating a new one for each marshall/unmarshall operation? Seems to me that it would be more fair... what protobuf does once at generate time, gob can do at runtime, but just once! Otherwise consider removing gob from the benchmark, it makes it seem really bad while it probably isn't.

Add benchmark for gjson

Please add benchmark for gjson (https://github.com/tidwall/gjson), it seems super fast.

Bebop "message" and "union" definition benchmarks

Hello,

It would be nice to have Bebop message and union definition(s) benchmarked as well. In practice, I find myself relying on message and union more often than bare struct and I suspect that would be the case for most non-trivial applications as well. Since these are less efficient than struct, it would be interesting to see how they fare.

Another XDR implementation

https://github.com/calmh/xdr

Add gRPC protobuf implementation

FlatBuffers can unmarshal without any allocations, yet there are some in the benchmark

Hi,

I noticed that the following code seems to be creating heap allocations, which may reflect unfairly on flatbuffers: https://github.com/alecthomas/go_serialization_benchmarks/blob/master/serialization_benchmarks_test.go#L475-L477

The code in question is:

    a.Name = string(o.Name())
    a.BirthDay = time.Unix(o.BirthDay(), 0)
    a.Phone = string(o.Phone())

Both string calls will create an allocation. FlatBuffers returns a []byte which should be sufficient :-)

why is greenpack and zebrapack not included in the benchmarks?

https://github.com/glycerine/greenpack

https://github.com/glycerine/zebrapack

How to test serializing a map?

What are your thoughts on how to test serialization of a map; for example, a map[string]string?

Stable input for benchmarks

I wonder what the idea behind choosing random elements on each benchmark step. I thought it would be nice to generate an item at the beginning of benchmarks and then use it for all operations. We could measure throughput with SetBytes in that case, and also, I think it would be a slightly more honest benchmark.
Thanks!

map[string]interface{} benchmrk

It would be also interesting to see the serialization/deserialization from/to a map[string]interface{} instead of just a struct

Adding CBOR serializers

CBOR is msgpack-like format on IETF standards track (RFC 7049)

• http://cbor.io
• https://tools.ietf.org/html/rfc7049

Golang implementations are:

• https://code.google.com/p/cbor/
• https://github.com/2tvenom/cbor

Both seem to have high level API interfaces that serialise arbitrary structs, so I think they can be added without too much work. I will try to add them in a pull request, unless you beat me to it.

If anyone has found them to be unstable or broken, please let me know.

thanks all!

nickg

Fair Comparison For Timestamps

The test data struct has a time.Time field. Formats which don't support timestamps now benefit from the fact that they compete with a plain integer.
To be fair, we could create time.Unix objects and make BirthDay as time.Now().Round(time.Seconds) to get rid of the nanoseconds or simply switch to int64 for all.

gob benchmark results are unrealistic and unfair

Last time I checked gob is the slowest encoding you can have in Go - yet in your benchmark it is the fastest. The reason seems to be that it is the only serializer that reuses encoder, decoder, and buffer. That is completely unrealistic and unfair. I understand that gob is slow without those optimizations but I doubt it is the right way to deal with it.

What does tt.kb means in marshall benchmarks?

total bytes of allocation?

or total bytes of serialization result? also tt.kb in deserialization means the struct size of deserialization result?

FlatBuffer Panic With VALIDATE Set

% go version
go version go1.5 darwin/amd64
% VALIDATE=1 go test -bench='.*' ./

A test suite for benchmarking various Go serialization methods.

See README.md for details on running the benchmarks.

PASS
BenchmarkVmihailencoMsgpackMarshal-8 1000000 2076 ns/op 400 B/op 6 allocs/op
BenchmarkVmihailencoMsgpackUnmarshal-8 500000 2901 ns/op 496 B/op 15 allocs/op
BenchmarkJsonMarshal-8 500000 2563 ns/op 584 B/op 7 allocs/op
BenchmarkJsonUnmarshal-8 300000 5071 ns/op 559 B/op 10 allocs/op
BenchmarkBsonMarshal-8 1000000 1600 ns/op 416 B/op 10 allocs/op
BenchmarkBsonUnmarshal-8 --- FAIL: BenchmarkBsonUnmarshal-8
serialization_benchmarks_test.go:315: unmarshaled object differed:
&{6ba41ebd83bd6a7c 2015-09-09 20:22:05.735954112 +0200 CEST 788dc877a6 4 false 0.49660976898283055}
&{6ba41ebd83bd6a7c 2015-09-09 20:22:05.735 +0200 CEST 788dc877a6 4 false 0.49660976898283055}
BenchmarkVitessBsonMarshal-8 1000000 1062 ns/op 1168 B/op 4 allocs/op
BenchmarkVitessBsonUnmarshal-8 --- FAIL: BenchmarkVitessBsonUnmarshal-8
serialization_benchmarks_test.go:315: unmarshaled object differed:
&{0561b476f8f2f9f9 2015-09-09 20:22:06.822174012 +0200 CEST 8342e65f20 4 false 0.12722105587509064}
&{0561b476f8f2f9f9 2015-09-09 18:22:06.822 +0000 UTC 8342e65f20 4 false 0.12722105587509064}
BenchmarkGobMarshal-8 200000 7609 ns/op 1808 B/op 35 allocs/op
BenchmarkGobUnmarshal-8 50000 34900 ns/op 9424 B/op 239 allocs/op
BenchmarkXdrMarshal-8 1000000 2000 ns/op 591 B/op 20 allocs/op
BenchmarkXdrUnmarshal-8 500000 2535 ns/op 383 B/op 13 allocs/op
BenchmarkUgorjiCodecMsgpackMarshal-8 500000 2522 ns/op 1905 B/op 10 allocs/op
BenchmarkUgorjiCodecMsgpackUnmarshal-8 500000 3654 ns/op 1984 B/op 16 allocs/op
BenchmarkUgorjiCodecBincMarshal-8 500000 2536 ns/op 1937 B/op 10 allocs/op
BenchmarkUgorjiCodecBincUnmarshal-8 --- FAIL: BenchmarkUgorjiCodecBincUnmarshal-8
serialization_benchmarks_test.go:315: unmarshaled object differed:
&{e80460e8f0256208 2015-09-09 20:22:18.400028604 +0200 CEST 206396d044 3 false 0.4436151940429639}
&{e80460e8f0256208 2015-09-09 20:22:18.400028604 +0200 +0200 206396d044 3 false 0.4436151940429639}
BenchmarkSerealMarshal-8 500000 3769 ns/op 928 B/op 21 allocs/op
BenchmarkSerealUnmarshal-8 300000 4563 ns/op 1248 B/op 36 allocs/op
BenchmarkBinaryMarshal-8 1000000 1658 ns/op 352 B/op 16 allocs/op
BenchmarkBinaryUnmarshal-8 500000 2753 ns/op 544 B/op 24 allocs/op
BenchmarkMsgpMarshal-8 5000000 321 ns/op 144 B/op 1 allocs/op
BenchmarkMsgpUnmarshal-8 1000000 1384 ns/op 208 B/op 5 allocs/op
BenchmarkGoprotobufMarshal-8 2000000 649 ns/op 320 B/op 4 allocs/op
BenchmarkGoprotobufUnmarshal-8 2000000 905 ns/op 432 B/op 9 allocs/op
BenchmarkGogoprotobufMarshal-8 10000000 179 ns/op 64 B/op 1 allocs/op
BenchmarkGogoprotobufUnmarshal-8 5000000 285 ns/op 112 B/op 3 allocs/op
BenchmarkProtobufMarshal-8 1000000 1120 ns/op 224 B/op 7 allocs/op
BenchmarkProtobufUnmarshal-8 1000000 1868 ns/op 336 B/op 12 allocs/op
BenchmarkHproseMarshal-8 1000000 1070 ns/op 495 B/op 8 allocs/op
BenchmarkHproseUnmarshal-8 1000000 2254 ns/op 416 B/op 12 allocs/op
BenchmarkFlatbuffersMarshal-8 5000000 340 ns/op 0 B/op 0 allocs/op
BenchmarkFlatBuffersUnmarshal-8 panic: runtime error: slice bounds out of range

goroutine 33 [running]:
github.com/google/flatbuffers/go.(_Table).Offset(0xc820053e58, 0xc, 0x1)
/Users/pkloe/Code/pascaldekloe/src/github.com/google/flatbuffers/go/table.go:15 +0x1b5
bu.(_FlatBufferA).Spouse(0xc820053e58, 0x1)
/Users/pkloe/Code/pascaldekloe/src/bu/FlatBufferA.go:51 +0x33
bu.BenchmarkFlatBuffersUnmarshal(0xc820144000)
/Users/pkloe/Code/pascaldekloe/src/bu/serialization_benchmarks_test.go:632 +0x4d2
testing.(_B).runN(0xc820144000, 0x1)
/usr/local/go/src/testing/benchmark.go:124 +0x9a
testing.(_B).launch(0xc820144000)
/usr/local/go/src/testing/benchmark.go:199 +0x63
created by testing.(*B).run
/usr/local/go/src/testing/benchmark.go:179 +0x54

goroutine 1 [runnable]:
testing.(_B).run(0xc820144000, 0x0, 0x0, 0x0, 0x0, 0x0)
/usr/local/go/src/testing/benchmark.go:180 +0x7b
testing.RunBenchmarks(0x874798, 0xa94440, 0x20, 0x20)
/usr/local/go/src/testing/benchmark.go:332 +0x75f
testing.(_M).Run(0xc82004fef8, 0xffffffff)
/usr/local/go/src/testing/testing.go:503 +0x1b8
main.main()
bu/_test/_testmain.go:118 +0x116

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1696 +0x1
exit status 2
FAIL bu 47.598s

I don't really understand the benchmark in the sense that...

tiny msgpack seems faster per iteration BUT gob is faster than tinymsgpack overall?

which is faster anyway? and what's the size of encoded result?

thrift benchmarks available.

I added Thrift Binary and CompactBinary benchmarks to my fork. Feel free to pull from

https://github.com/glycerine/go_serialization_benchmarks

if you wish.

Cap’n Proto

http://kentonv.github.io/capnproto/
Go lib: https://github.com/glycerine/go-capnproto

Add thrift implementation

Gob is the fastest

Hi,

just ran your benchmark with the following results on go1.3.1 mac 10.9.4:

PASS
BenchmarkUgorjiMsgpackMarshal 500000 3881 ns/op
BenchmarkUgorjiMsgpackUnmarshal 500000 3605 ns/op
BenchmarkVmihailencoMsgpackMarshal 1000000 1723 ns/op
BenchmarkVmihailencoMsgpackUnmarshal 1000000 2004 ns/op
BenchmarkJsonMarshal 500000 3044 ns/op
BenchmarkJsonUnmarshal 500000 5108 ns/op
BenchmarkBsonMarshal 1000000 2055 ns/op
BenchmarkBsonUnmarshal 1000000 2322 ns/op
BenchmarkVitessBsonMarshal 1000000 1438 ns/op
BenchmarkVitessBsonUnmarshal 2000000 849 ns/op
BenchmarkGobMarshal 500000 6765 ns/op
BenchmarkGobUnmarshal 50000 48796 ns/op
BenchmarkXdrMarshal 1000000 2641 ns/op
BenchmarkXdrUnmarshal 1000000 1968 ns/op
BenchmarkUgorjiCodecMsgpackMarshal 500000 3701 ns/op
BenchmarkUgorjiCodecMsgpackUnmarshal 500000 3860 ns/op
BenchmarkUgorjiCodecBincMarshal 500000 5072 ns/op
BenchmarkUgorjiCodecBincUnmarshal 500000 4903 ns/op
BenchmarkSerealMarshal 500000 4509 ns/op
BenchmarkSerealUnmarshal 500000 3796 ns/op
BenchmarkBinaryMarshal 1000000 2196 ns/op
BenchmarkBinaryUnmarshal 1000000 2216 ns/op
ok github.com/alecthomas/go_serialization_benchmarks 49.228s

Outstanding:

BenchmarkGobMarshal 500000 6765 ns/op
BenchmarkGobUnmarshal 50000 48796 ns/op

Is this a bug or is this real ?