Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

convertVarIntToBytes: use reusable bytes array not expensive, discarded bytes.Buffer #352

Merged
merged 2 commits into from
Dec 17, 2020
Merged

convertVarIntToBytes: use reusable bytes array not expensive, discarded bytes.Buffer #352

merged 2 commits into from
Dec 17, 2020

Conversation

odeke-em
Copy link
Contributor

Noticed while auditing and profiling dependencies of cosmos-sdk, that
convertVarIntToBytes, while reusing already implemented code, it
was expensively creating a bytes.Buffer (40B on 64-bit architectures)
returning a result and discarding it, yet that code was called
3 times successively at least.

By reusing a byte array (not a slice, to ensure bounds checks
eliminations by the compiler), we are able to dramatically improve
performance, taking it from ~4µs down to 850ns (~4.5X reduction),
reduce allocations by >=~80% in every dimension:

$ benchstat before.txt after.txt
name             old time/op    new time/op    delta
ConvertLeafOp-8    3.90µs ± 1%    0.85µs ± 4%  -78.12%  (p=0.000 n=10+10)

name             old alloc/op   new alloc/op   delta
ConvertLeafOp-8    5.18kB ± 0%    0.77kB ± 0%  -85.19%  (p=0.000 n=10+10)

name             old allocs/op  new allocs/op  delta
ConvertLeafOp-8       120 ± 0%        24 ± 0%  -80.00%  (p=0.000 n=10+10)

Fixes #344

Copy link
Contributor

@erikgrinaker erikgrinaker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR!

encoding_test.go Outdated Show resolved Hide resolved
…ed bytes.Buffer

Noticed while auditing and profiling dependencies of cosmos-sdk, that
convertVarIntToBytes, while reusing already implemented code, it
was expensively creating a bytes.Buffer (40B on 64-bit architectures)
returning a result and discarding it, yet that code was called
3 times successively at least.

By reusing a byte array (not a slice, to ensure bounds checks
eliminations by the compiler), we are able to dramatically improve
performance, taking it from ~4µs down to 850ns (~4.5X reduction),
reduce allocations by >=~80% in every dimension:

```shell
$ benchstat before.txt after.txt
name             old time/op    new time/op    delta
ConvertLeafOp-8    3.90µs ± 1%    0.85µs ± 4%  -78.12%  (p=0.000 n=10+10)

name             old alloc/op   new alloc/op   delta
ConvertLeafOp-8    5.18kB ± 0%    0.77kB ± 0%  -85.19%  (p=0.000 n=10+10)

name             old allocs/op  new allocs/op  delta
ConvertLeafOp-8       120 ± 0%        24 ± 0%  -80.00%  (p=0.000 n=10+10)
```

Fixes #344
@odeke-em
Copy link
Contributor Author

@erikgrinaker please take a look, I’ve addressed your comments. Thank you!

@erikgrinaker erikgrinaker merged commit b2dffed into cosmos:master Dec 17, 2020
@erikgrinaker
Copy link
Contributor

Thanks @odeke-em!

@odeke-em odeke-em deleted the gut-out-buffer-allocations+immediate-discard branch December 17, 2020 10:27
@odeke-em
Copy link
Contributor Author

Thank you @erikgrinaker for the review! Could you please help me cut a new release too? I ask because it would be nice for us to get the cosmos-sdk team to use the latest code as well as the changes you made over the weekend fixing identified issues.

@erikgrinaker
Copy link
Contributor

We cut 0.15.2 on Monday, the only change which isn't included is this one.

@odeke-em
Copy link
Contributor Author

Gotcha, thanks for the update. If you are able to, I kindly request that you help me cut a point release with this code included, as when I (memory and cpu) profile gaiad, iavl code shows up, and am investigating.

@erikgrinaker
Copy link
Contributor

@odeke-em
Copy link
Contributor Author

Thank you @erikgrinaker!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants