No Description
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Morgan Bazalgette fec7b21875 Update readme 5 months ago
.travis.yml Add travis 2 years ago
LICENSE Initial commit 2 years ago
README.md Update readme 5 months ago
binary.go Use [8]byte in the struct instead of pool 5 months ago
read_float.go ReadChain is an useless clusterfuck. Change from ReadChain to Reader 2 years ago
read_int.go ReadChain is an useless clusterfuck. Change from ReadChain to Reader 2 years ago
read_test.go ReadChain is an useless clusterfuck. Change from ReadChain to Reader 2 years ago
read_uint.go Use [8]byte in the struct instead of pool 5 months ago
write_float.go Initial commit 2 years ago
write_int.go Initial commit 2 years ago
write_test.go Add ByteSlice and String 5 months ago
write_uint.go Add ByteSlice and String 5 months ago

README.md

GoDoc Build Status

binary

A faster binary encoder.

go get howl.moe/binary

Migrating to version 2

All slice-related methods have been removed - this is because they allocated their own slices (for reads). The way slices are implemented in binary protocols is often arbitrary, some specify the length, some only in certain cases, some use varints, others use different widths for the length. For this reason, we removed the methods.

ByteSlice and String have been kept, since those are even used internally.

There is no way to read a string directly like there was in the previous version - this is because of the aforementioned variability in implementation about encoding the length. You can still use the newly-added Read method (implements io.Reader) passing a byte slice with the length desired.

Why you should

The biggest, yet simplest, change was by removing all slice allocations. This is a common trick used often, in places such as fasthttp and nanojson (yes, that’s what we call shameless advertising.)

Previously, every single tiny read and write allocated a byte slice. This is actually quite expensive - it is a heap allocation, which needs to be tracked by the garbage collector, and so on. Now the byte slice is pre-allocated in the Reader/WriteChain itself (as an array, buf [8]byte, which is then used as a slice, ie. c.buf[:]). This gives significant performance boosts:

$ git checkout v1
$ go test -bench=.
goos: linux
goarch: amd64
pkg: github.com/thehowl/binary
BenchmarkWriteSmall-4    	30000000	        36.4 ns/op
BenchmarkWriteMedium-4   	 5000000	       263 ns/op
BenchmarkWriteLong-4     	 1000000	      1649 ns/op
PASS
ok  	github.com/thehowl/binary	4.421s

$ git checkout master
$ go test -bench=.
goos: linux
goarch: amd64
pkg: github.com/thehowl/binary
BenchmarkWriteSmall-4    	100000000	        20.0 ns/op
BenchmarkWriteMedium-4   	20000000	        91.7 ns/op
BenchmarkWriteLong-4     	 3000000	       412 ns/op
PASS
ok  	github.com/thehowl/binary	5.630s

As you can see, for writes of large chunks of data, this can be up to a 4x improvement.