When timeout is not hit `time.After` will leak unnecessary timer, so
it's better to stop timer explicitly.
Signed-off-by: Alexander Morozov <lk4d4math@gmail.com>
This change saves a lot of memory by reusing the underlying
gzip.{Writer,Reader}, which allocates up to 1.4mb at every instanciation
according to [1]. This was fixed by adding a Reset method by to the
object at [2].
The amount of memory (and GC time) saved is pretty high, as reported by
pprof:
flat flat% sum% cum cum%
28.33GB 85.70% 85.70% 32.74GB 99.05% compress/flate.NewWriter
flat flat% sum% cum cum%
19.39MB 16.74% 16.74% 22.07MB 19.05% compress/flate.NewWriter
And the benchmarks:
benchmark old ns/op new ns/op delta
BenchmarkGZIPCompressor1B-4 215170 22291 -89.64%
BenchmarkGZIPCompressor1KiB-4 225971 27213 -87.96%
BenchmarkGZIPCompressor8KiB-4 246696 54785 -77.79%
BenchmarkGZIPCompressor64KiB-4 444851 286924 -35.50%
BenchmarkGZIPCompressor512KiB-4 2279043 2115863 -7.16%
BenchmarkGZIPCompressor1MiB-4 4412989 4258635 -3.50%
benchmark old allocs new allocs delta
BenchmarkGZIPCompressor1B-4 17 0 -100.00%
BenchmarkGZIPCompressor1KiB-4 17 0 -100.00%
BenchmarkGZIPCompressor8KiB-4 17 0 -100.00%
BenchmarkGZIPCompressor64KiB-4 17 0 -100.00%
BenchmarkGZIPCompressor512KiB-4 17 0 -100.00%
BenchmarkGZIPCompressor1MiB-4 17 0 -100.00%
benchmark old bytes new bytes delta
BenchmarkGZIPCompressor1B-4 813872 8 -100.00%
BenchmarkGZIPCompressor1KiB-4 813872 16 -100.00%
BenchmarkGZIPCompressor8KiB-4 813875 27 -100.00%
BenchmarkGZIPCompressor64KiB-4 813918 190 -99.98%
BenchmarkGZIPCompressor512KiB-4 814928 1871 -99.77%
BenchmarkGZIPCompressor1MiB-4 820889 9735 -98.81%
[1] https://github.com/golang/go/issues/6138
[2] db12f9d4e4
Signed-off-by: Steeve Morin <steeve.morin@gmail.com>
ServerOption panics when fields that have been manually set are
subsequently set again. The message verbiage of `X has been set` is
unclear since `has been set` without an adverb like `already` does not
correctly convey that the fields are set-once and were previously set.
At the worst, the original verbiage `X has been set` could imply that
the new value would have been acceptable but another error occurred.
We discovered this while conducting a code survey for implementing
extensible stubs and uniform inbound interception API.
This change ensures consistency for the user when accessing metadata values:
they are never encoded except when sent on the wire. Previously, they would
appear encoded to client code, but not to server code. As such, this
represents a behavior change, but one unlikely to affect user code, as it's
unusual to inspect the metadata after setting it.
