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.

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 :-)

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.

This PR fixes #13 and #14 .

The generated code is in structdef_gen.go. I'll send you another PR if the the code generator ends up writing substantially different code in the future.

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?

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.

Fixes #64

Should probably regenerate the report on golang 1.9 with the latest packages. I can do that as well if you feel comfortable or you can run it after merging @alecthomas

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

The default vitess bson API uses reflection, which is slow. Vitess also provides a code generator (bsongen), which I used to generate a custom encoder/decoder. I started off with this: BenchmarkVitessBsonMarshal 100000 16843 ns/op BenchmarkVitessBsonUnmarshal 500000 5185 ns/op

Reduced the default excessive buffer allocation from 16K to 1K: BenchmarkVitessBsonMarshal 500000 4772 ns/op BenchmarkVitessBsonUnmarshal 500000 5416 ns/op

Used generated code: BenchmarkVitessBsonMarshal 1000000 2083 ns/op BenchmarkVitessBsonUnmarshal 1000000 1158 ns/op

We'll work on reducing the default buffer size from 16K to 1K. It will take us a few iterations to get there.

PS: Accept this CL only if you think it's fair, because other APIs don't use generated code.

We're doing a lot of jsonpb encoding and decoding and it is not fast. Wanted to benchmark it along with everything else.

Also added mongodb's bson lib since a lot of newer work is using this lib instead of mgo.

I didn't see this in the readme, but I had to feed the output of the benchmarks out like go test -bench='.*' ./ > results.txt for the readme table generation script to produce output.

Let me know if you would prefer I run the benchmarks on my osx machine for a more similar comparison to the last benchmark.

Bumps github.com/shamaton/msgpack/v2 from 2.0.0 to 2.1.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

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.

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

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?