Allocation optimization #33
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
Add assertions to ensure ECDSA signing methods return valid signatures. This is probably covered elsewhere as well, but putting it in ecdsa_test.go makes it more obvious and easier to find.
|
Port of dgrijalva/jwt-go#455. |
amnonbc
reviewed
Jul 6, 2021
oxisto
reviewed
Jul 6, 2021
amnonbc
previously approved these changes
Jul 6, 2021
jkanywhere
force-pushed
the
allocation-optimization
branch
from
fcd234c
to
35d09fe
Compare
Thanks.
Done. |
Add benchmark coverage of ECDSA signing methods. Benchmarks are run using the existing helper for comparability with existing benchmarks. Sign method is also tested directly, to avoid the overhead of *Token. Report allocations for all benchmarks. Allocation count for ES384 and ES512 fluctuate across test runs, other signing methods consistently report the same number of allocations. Sample output: ``` $ go test -bench=Bench -run=NONE . 2021/02/26 18:18:30 Listening... goos: darwin goarch: amd64 pkg: github.com/dgrijalva/jwt-go BenchmarkECDSASigning/Basic_ES256-8 190572 6702 ns/op 4249 B/op 65 allocs/op BenchmarkECDSASigning/Basic_ES256/sign-only-8 47383 24650 ns/op 3329 B/op 43 allocs/op BenchmarkECDSASigning/Basic_ES384-8 1113 1252975 ns/op 1750744 B/op 14474 allocs/op BenchmarkECDSASigning/Basic_ES384/sign-only-8 286 3937773 ns/op 1746175 B/op 14423 allocs/op BenchmarkECDSASigning/Basic_ES512-8 662 1949937 ns/op 3028386 B/op 19608 allocs/op BenchmarkECDSASigning/Basic_ES512/sign-only-8 170 6856189 ns/op 3025471 B/op 19571 allocs/op BenchmarkECDSASigning/basic_ES256_invalid:_foo_=>_bar-8 190638 6665 ns/op 4249 B/op 65 allocs/op BenchmarkHS256Signing-8 1000000 1024 ns/op 1584 B/op 32 allocs/op BenchmarkHS384Signing-8 917286 1447 ns/op 1969 B/op 32 allocs/op BenchmarkHS512Signing-8 827744 1470 ns/op 2065 B/op 32 allocs/op BenchmarkRS256Signing-8 3037 390077 ns/op 32576 B/op 136 allocs/op BenchmarkRS384Signing-8 2976 379155 ns/op 32684 B/op 136 allocs/op BenchmarkRS512Signing-8 3205 388628 ns/op 32704 B/op 136 allocs/op ```
Reduce the number of byte arrays allocated by using big.Int.FillBytes when calculating ECDSA signature. After this change, Benchmarks of ES256 signing method consistently report 4 fewer allocations. Before: ``` BenchmarkECDSASigning/Basic_ES256-8 190572 6702 ns/op 4249 B/op 65 allocs/op BenchmarkECDSASigning/Basic_ES256/sign-only-8 47383 24650 ns/op 3329 B/op 43 allocs/op ``` After: ``` BenchmarkECDSASigning/Basic_ES256-8 187682 6725 ns/op 4121 B/op 61 allocs/op BenchmarkECDSASigning/Basic_ES256/sign-only-8 48656 24446 ns/op 3201 B/op 39 allocs/op ```
JWT uses a non-padded base64 encoding. Current code uses base64.URLEncoding to generate a padded string and then removes the padding. Likewise, current code adds padding before decoding. Instead, use base64.RawURLEncoding which does not add or require the padding in the first place. In addition to making the code cleaner, this reduces memory allocations as reported by benchmarks. Before: ``` BenchmarkECDSASigning/Basic_ES256-8 191396 6917 ns/op 4121 B/op 61 allocs/op BenchmarkECDSASigning/Basic_ES256/sign-only-8 49347 25039 ns/op 3201 B/op 39 allocs/op BenchmarkECDSASigning/basic_ES256_invalid:_foo_=>_bar-8 190668 6586 ns/op 4121 B/op 61 allocs/op BenchmarkHS256Signing-8 1260060 1131 ns/op 1585 B/op 32 allocs/op BenchmarkHS384Signing-8 861378 1387 ns/op 1969 B/op 32 allocs/op BenchmarkHS512Signing-8 896745 1463 ns/op 2065 B/op 32 allocs/op BenchmarkRS256Signing-8 3086 355769 ns/op 32576 B/op 136 allocs/op BenchmarkRS384Signing-8 3414 353570 ns/op 32694 B/op 136 allocs/op BenchmarkRS512Signing-8 3235 349394 ns/op 32706 B/op 136 allocs/op ``` After: ``` BenchmarkECDSASigning/Basic_ES256-8 176617 6827 ns/op 4021 B/op 58 allocs/op BenchmarkECDSASigning/Basic_ES256/sign-only-8 48038 24213 ns/op 3169 B/op 38 allocs/op BenchmarkECDSASigning/basic_ES256_invalid:_foo_=>_bar-8 194352 6928 ns/op 4021 B/op 58 allocs/op BenchmarkHS256Signing-8 1000000 1127 ns/op 1488 B/op 29 allocs/op BenchmarkHS384Signing-8 972552 1369 ns/op 1873 B/op 29 allocs/op BenchmarkHS512Signing-8 780751 1368 ns/op 1969 B/op 29 allocs/op BenchmarkRS256Signing-8 3014 387326 ns/op 32475 B/op 133 allocs/op BenchmarkRS384Signing-8 3044 361411 ns/op 32591 B/op 133 allocs/op BenchmarkRS512Signing-8 3273 355504 ns/op 32607 B/op 133 allocs/op ``` Benchmarks of signing methods ES384 and ES512 are omitted because their allocations are not consistent.
jkanywhere
force-pushed
the
allocation-optimization
branch
from
35d09fe
to
5073985
Compare
Cool... |
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.
Add benchmark coverage of ECDSA signing methods.
Reduce memory allocations for ECDSA signing by using big.Int.FillBytes instead of allocating and copying bytes directly.
FillByteswas added in go 1.15.Use base64.RawURLEncoding to avoid having to add and remove
=padding.Benchmark results
Before optimizations, as of ff7295f:
After optimizations:
Output of
BenchmarkECDSASigningwith ES384 and ES512 are omitted because theallocations change for each execution.