mirror of https://github.com/grpc/grpc-go.git
c91d17acf1
This commit introduces the first microbenchmark for grpc, wherein `encode` is benchmarked according to message size. A conclusion of the benchmark is that the removal of type switching found in `binary.Write`, which is used in `encode` produces the following encoding time and memory allocation footprint: ``` $ # Return to previous commit but benchmark. $ go test ./... -test.bench="Benchmark*" > /tmp/before $ # Return to working copy. $ go test ./... -test.bench="Benchmark*" > /tmp/after $ benchcmp /tmp/before /tmp/after benchmark old ns/op new ns/op delta BenchmarkEncode1B 1282 936 -26.99% BenchmarkEncode1KiB 4865 4184 -14.00% BenchmarkEncode8KiB 22686 21560 -4.96% BenchmarkEncode64KiB 134451 116762 -13.16% BenchmarkEncode512KiB 514044 361224 -29.73% BenchmarkEncode1MiB 767096 636725 -17.00% benchmark old MB/s new MB/s speedup BenchmarkEncode1B 6.24 8.55 1.37x BenchmarkEncode1KiB 212.11 246.63 1.16x BenchmarkEncode8KiB 361.46 380.33 1.05x BenchmarkEncode64KiB 487.50 561.35 1.15x BenchmarkEncode512KiB 1019.94 1451.45 1.42x BenchmarkEncode1MiB 1366.95 1646.84 1.20x benchmark old allocs new allocs delta BenchmarkEncode1B 6 3 -50.00% BenchmarkEncode1KiB 8 5 -37.50% BenchmarkEncode8KiB 8 5 -37.50% BenchmarkEncode64KiB 8 5 -37.50% BenchmarkEncode512KiB 8 5 -37.50% BenchmarkEncode1MiB 8 5 -37.50% benchmark old bytes new bytes delta BenchmarkEncode1B 384 328 -14.58% BenchmarkEncode1KiB 2816 2760 -1.99% BenchmarkEncode8KiB 17283 17227 -0.32% BenchmarkEncode64KiB 147856 147802 -0.04% BenchmarkEncode512KiB 1065344 1065288 -0.01% BenchmarkEncode1MiB 2113920 2113864 -0.00% ``` ..., which is apropos of the comment in [encoding/binary] (http://golang.org/pkg/encoding/binary), wherein ... > This package favors simplicity over efficiency. ... is stated. If `encode` is deemed to need further memory efficiencies, a mechanism whereby a `proto.Buffer` is retained may be warranted, which is why the original TODO remains. The proposed improvement in this change is simple and low-hanging. I did not want to introduce yet-another protocol buffer message for tests, but the ones under ... > interop/grpc_testing/test.proto > test/grpc_testing/test.proto ... have a fundamental dependency on `grpc` package due to their generated stubs, which produces a cycle in the imports if the benchmark were to attempt to import them for profiling. The newly created ... > test/grpc_message/test.proto ... protocol buffer package has no generated RPC service stubs, which means it can be imported into the `grpc` package root without cycle. |
||
|---|---|---|
| .. | ||
| perf.pb.go | ||
| perf.proto | ||