You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The encoding/binary package performs more slowly writing uint{8,16,32,64} data vs the corresponding int{8,16,32,64} data. The performance when writing *uints and *ints is almost identical.
Here is part of the output from running the benchmark test.
>go test binary1.go binary1_test.go -bench=.
testing: warning: no tests to run
PASS
BenchmarkWrite_int8 10000 171109 ns/op
BenchmarkWrite_uint8 5000 367821 ns/op
BenchmarkWrite_int8_p 10000 114706 ns/op
BenchmarkWrite_uint8_p 10000 115306 ns/op
The results for larger integers are similar.
The problem appears to be in the encoding/binary package's intDataSize function:
// intDataSize returns the size of the data required to represent the data when encoded.
// It returns zero if the type cannot be implemented by the fast path in Read or Write.
func intDataSize(data interface{}) int {
switch data := data.(type) {
case int8, *int8, *uint8:
return 1
case []int8:
return len(data)
case []uint8:
return len(data)
The first case of the switch does not include uint8 so the fast path is not used. The data size is looked up later using reflection instead of using this hard coded size. Larger unsigned ints are also missing later in the switch.
The text was updated successfully, but these errors were encountered:
mikioh
changed the title
encoding/binary package performance for signed vs unsigned integers
encoding/binary: package performance for signed vs unsigned integers
Feb 21, 2015
The
encoding/binary
package performs more slowly writinguint{8,16,32,64}
data vs the correspondingint{8,16,32,64}
data. The performance when writing*uints
and*ints
is almost identical.See
binary1.go
in http://play.golang.org/p/--qpN-sy6o andbinary1_test.go
in http://play.golang.org/p/ypH8OTtYYxHere is part of the output from running the benchmark test.
The results for larger integers are similar.
The problem appears to be in the
encoding/binary
package'sintDataSize
function:The first case of the switch does not include
uint8
so the fast path is not used. The data size is looked up later using reflection instead of using this hard coded size. Larger unsigned ints are also missing later in the switch.The text was updated successfully, but these errors were encountered: