No allocations on EncodeTime, run benchmarks
#224
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
smira
added a commit
to smira/zap-msgpack-encoder
that referenced
this pull request
Mar 26, 2019
We anyway need to cache in sync.Pool instances of msgpack Encoder object, and this object is bound to Writer instance (Buffer in our case). There's no way to reset encoder to use different buffer, and there's no way to avoid buffer from being recycled if returned, so it's easier to use bytes.Buffer which has necessary APIs to avoid extra allocations (see uber-go/zap#691). The only allocation left in the benchmark is from msgpack's EncodeTime function, PR is submitted for it: vmihailenco/msgpack#224
vmihailenco
reviewed
Mar 27, 2019
encode.go
Outdated
| @@ -53,6 +53,8 @@ type Encoder struct { | |||
| w writer | |||
| buf []byte | |||
|
|
|||
| tbuf []byte | |||
There was a problem hiding this comment.
Please group this with other buf var and rename to timeBuf. Also having a comment why we need another buffer ("We can't use use e.buf, as it's used to encode extLen") will help future readers a lot.
Use per-instance lazily-allocated buffer to avoid allocations in `EncodeTime`. We can't use use `e.buf`, as it's used to encode extLen, and it's smaller than required (9 bytes). Using buffer on stack doesn't work, as Go doesn't have a way to figure out if `e.write(b)` escapes or not, so it thinks it always escapes. Run benchmarks for `make` (and in Travis CI), and fix benchmark which was failing probably due to some changes in the codebase. Benchmark, before: ``` BenchmarkTime-12 20000000 94.0 ns/op 8 B/op 1 allocs/op ``` after: ``` BenchmarkTime-12 20000000 76.7 ns/op 0 B/op 0 allocs/op ```
smira
force-pushed
the
encode-time-no-allocs
branch
from
f65f98d
to
687c5aa
Compare
|
Thank you! |
|
would you mind tagging new release with this commit please? |
|
Tagged v4.0.4 |
smira
added a commit
to smira/zap-msgpack-encoder
that referenced
this pull request
Mar 27, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Use per-instance lazily-allocated buffer to avoid allocations
in
EncodeTime. We can't use usee.buf, as it's used toencode extLen, and it's smaller than required (9 bytes).
Using buffer on stack doesn't work, as Go doesn't have
a way to figure out if
e.write(b)escapes or not, so it thinksit always escapes.
Run benchmarks for
make(and in Travis CI), and fix benchmarkwhich was failing probably due to some changes in the codebase.
Benchmark, before:
after: